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В. Arbinger, І. Krüger 

Scriptum 

Das leistungsfähige Textverarbei 
tungsprogramm für den Amiga. 
Die Diskette enthält Scriptum, das 
Programm, mit dem Schreiben auf 
dem Amiga zum Vergnügen wird 
Dazu eine ausführliche Programm- 
beschreibung im Buch, die bei allen 
Fragen weiterhilft 

1989, 141 Seiten 

inkl. Programmdiskette. 

ISBN 3-89090-650-8 

DM 79,-* (sFr 72,70*/6S 672.-*) 


Precision Software 

Amiga Superbase 

Die Einsteiger-Datenbank. Relationa- 
les System zum Verwalten von Daten 
aller Art, auch von IFF-Grafiken; mit 
integrierter Diashow-Funktion 

1989, 176 Seiten 

inkl. Programmdiskette. 

ISBN 3-89090-791-1 

DM 89,-* (sFr 81,90°/6S 757,-”) 
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Atlantis 

АтідаСа!! 

Treten Sie ein іп die faszinierende 
Welt der Datenfernübertragung. 
Kommunizieren Sie über Mailboxen 
mit erfahrenen Computer-Anwendern, 
die Ihnen bei Ihren Problemen wei 
terhelfen können, oder Sie erhalten 
auf diesem Wege leistungsfáhige 
Public-Domain-Software. 

1988, 133 Seiten, 

inklusive Programmdiskette. 

ISBN 3-89090-716-4, 

DM 99,-* (sFr 91,-"/55 842,-*) 


С. Fuchs 

Reflections 

Traumwelt und Realismus - Bilder im 
Raytracing-Verfahren auf dem 
Amiga. Dazu im Buch eine ausführ- 
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liche Bedienungsanleitung mit vielen 
Tips und Tricks. 

1989, 156 Seiten, 

inklusive Programmdiskette. 

ISBN 3-89090-727-X, 

DM 98,-* (sFr 90,20*, 6S 834,-*) 


Atlantis 

Trickstudio A 

Animationen in Bild und Ton. Ein 
Programm zum einfachen Erstellen 
und Abspielen von bewegten 
Bildern, die synchron mit Sound 
unterlegt werden können. Dazu eine 
ausführliche Dokumentation für die 
effektive Anwendung 

1988, 86 Seiten, 

inklusive Programmdiskette. 

ISBN 3-89090-715-6, 

DM 99,-* (sFr 91,-"/öS 842.-") 
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NFO-COUPON 


Bitte senden Sie mir Ihr Gesamtverzeichnis 
| mit 500 aktuellen Computerbüchern und Software 


tr. 2, 8013 Haar 
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In Vorbereitung: 

N. Wirsing 

Amiga Audio Entwickler-Paket 
Dieses Buch macht Sie zum 
perfekten Amiga-Tontechniker. 
Lieferbar 3. Quartal '89, 

ca. 400 Seiten, 

inkl. 2 Programmdisketten 

ISBN 3-89090-765-2. 

са. DM 98,-* (sFr 90,20°/6S 834-) 


In Vorbereitung: 

H. Knappe 

Amiga Sounder 

Der Amiga Sounder ist ein Komplett. 
paket für den Einstieg in die Welt der 
digitalen Klánge. 

Lieferbar 3. Quartal 1989, 

ca. 120 Seiten 

inkl 2 Programmdisketten. 

ISBN 3-89090-709-1 

ca. ОМ 98,-* (sFr 90,20°/6S 834,-*) 


“Unverbindliche Preisempfehlung 


Markt&Technik-Produkte 
erhalten Sie bei Ihrem Buch- 
oder Computerfachhändler 


Game 
Over 


& Tilt! Verdammte $%8&? #8)! Jetzt 
habe ich die Nase voll und 
Schreib mein eigenes Spiel. Warum 
auch nicht? 
Ф Schnell noch Assembler gelernt, 
ein paar Grafiken über den Bild- 
schirm geblittert, das Betriebssystem 
abgeschaltet und Kopf voraus in den 
Supervisor-Modus. 
@ Und dann? Natürlich gehört es 
zum guten Ton, einige heiße 
Soundeffects eiskalt unterzumischen. 
Noch schnell die Copperliste manipu- 
lieren und einige Interrupts verbiegen. 
Wozu hat mein Amiga mindestens 
4194304 einzelne Bits? Wer soll die 
setzen, wenn nicht ich? Devices und 
ähnlicher Schnickschnack - weg da- 
mit. Programmstruktur? Schön chao- 
tisch - es braucht ja nicht jeder wissen, 
mit welchen Tricks ich arbeite. 
e Somit haben wir alle Zutaten für 
ein perfektes Spiel. Garnieren wir 
das Ganze noch mit einem netten Vor- 
spann und einem möglichst außerirdi- 
schen Namen, und schon ist der Erfolg 
programmiert. 

Aber fehlt da nicht noch was? Ach 
© ja, die Spielidee - nach soviel 
»perfektem« Programmieren wird sich 
da sicher noch was ergeben. 


Error 


Ist es da ein Wunder, daß noch 

immer die meisten Leute am lieb- 
sten Schach spielen? Warum wird die- 
ses Spiel nicht langweilig, obwohl es 
seit Jahrtausenden »auf dem Markt« 
ist? Sehr einfach: Es lebt von einer ge- 
nialen Idee. 
9 An dieser scheint es den meisten 

Computerspielen zu mangeln. 
Jedenfalls werden sie meist schon 
nach einigen Tagen nur noch von weni- 
gen gespielt, gelten als fade und ab- 


gelutscht. 
Also tatsách- 
lich »Game 


Over«? Sicher, es 
gibt einige rühmli- 
che Ausnahmen. 
Dennoch treffen 
die oben genann- 
ten Merkmale - lei- 
der - auf die mei- 
sten Spiele zu. 

Machen Sie 

sich also zu- 
nächst auf die Su- 
che nach einer gu- 
ten Idee für Ihr 
Spiel. Sie werden 
für jeden Ansatz 
auch eine programmtechnische Lö- 
sung finden. Das nötige Know-how fin- 
den Sie in diesem Heft. Die Ideen müs- 
sen Sie schon selbst haben. 


Ihr 
Klaus Sonnenleiter 
(Redakteur) = 


— 
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6 Am Anfang war die Idee 
Verfolgen Sie die Entstehung eines Spiels vom 
Entwurf bis zum fertigen Programm. 


22 Auf dem Weg zu neuen Welten 
Erleben Sie die Faszination der Vektor-Grafik. Hohe 
Geschwindigkeit, geringer Speicherverbrauch und 
schnelle Entwürfe sind die Stärke dieser Form der 
grafischen Berechnung. 


28 Kreuzzüge 
Es gibt eine unüberschaubare Zahl an 
Programmiersprachen. Welchem Guru sollen Sie 
folgen? Hier finden Sie »die« Lösung. 


30 Brücke zwischen den Welten 
C und Modula gelten unter Programmierern als zwei 
Welten. Diese müssen jedoch nicht unüberbrückbar 
bleiben. Frank Staudte erklärt wie's geht. 


36 Ungleiche Brüder 


Basic ist für fast jeden der Einstieg in die 
Programmierung des Amiga. Oft wird jedoch allzu 
schnell der Ruf nach einer anderen 
Programmiersprache laut. Jürgen Singer erleichtert 
Ihnen den Umstieg. 


39 cc2lc - ganz einfach? 
Aztec und der Lattice sind Compiler für dieselbe 
Sprache. Dennoch treten immer wieder Probleme 
bei der Konvertierung auf. Ralph Babel zeigt, wie Sie 
diese umgehen. 


44 Spiel mit Zahlen 


Mathematische Spieltheorie ist eine unverzichtbare 
Grundlage für erfolgreiche Spieleprogrammierung. 
Lassen Sie sich von Jürgen Singer in die Welt der 

Zahlen und Spielzüge entführen. 


53 Cola, Fanta, Sprite 
Was sind Spiele ohne Sprites? Richtig, Suppe ohne 
Salz. Hier sehen Sie, wie Sie Hardwaresprites richtig 
einsetzen. 


57 Sprites virtuell 


Die Hardware des Amiga ist auf maximal acht Sprites 
festgelegt. Wenn das nicht ausreicht, müssen Sie auf 
VSprites zurückgreifen. 


62 Blitters Objekte 


Die flexibelste Form der Sprites sind die »BObs«. 
Diese werden vom Blitter verwaltet und können 
daher leichter direkt beeinflußt werden. 


66 Nimm zwei 
Bewegte Grafiken mit statischen Komponenten 
werden mit nur einem Screen schnell zum Problem. 
Die Lösung ist einfach: Wir nehmen zwei und 
machen den oberen halb durchsichtig. 


68 Flacker-Fixer 


Bewegte Grafiken sind nur überzeugend, wenn sie 
fließend und ohne zu flackern über den Bildschirm 
gleiten. Double-Buffering macht's möglich. 


72 Blitt-schnelle Grafik 


Die Grafikfähigkeiten des Amiga werden vorwiegend 
einem einzigen Chip »angelastet«: dem Blitter. Hier 
erfahren Sie, wie Sie direkt auf diesen zugreifen. 


75 Kein Joy ohne Stick 


Durch eine unsaubere oder langsame 
Joystickabfrage kann ein Spiel zum Wahnsinn 
treiben. Von Arno Gölzer erfahren Sie, wie Sie diesen 
»Lustknüppel« schnell und fehlerfrei abfragen. 


Eine 
zündende 
Idee bildet 
den Start- 
schuß zur 
Programmie- 
rung Ihres 
Spiels 


SEITE 6 


Die bell eigeranten Bereiche werden vom Program sige- 
fragt өмі mmipelient. Die angegebenen Koordinaten der 
Бегей» den Rechteche wurden mit Waist ІП in ket- 
ber geen ermittelt. 


Schiebung ohne Ende - so einfach wie es aussieht, 
hat man gegen den Computer nicht SEITE 90 


gewonnen 
77 Grafik am laufenden Band u 


Betätigen Sie sich als Kulissenschieber. 
Mit »Superbitmaps« ist das kein Problem. 


81 Intuition ausgebremst EI 
Für schnelle Grafikausgabe ist der 
Verwaltungsaufwand von Intuition eher im Weg. 

Also: Weg damit und ran ап das eigene Display. 


84 An der Coppercabana H 


16 Farben mit zwei Bitplanes - unmóglich sagen Sie? 
Kein Problem, wenn Sie die Hilfe des Copper bemühen. 


88 Der Sturz ins Bodenlose H 


»Wer raufsteigt, wird auch wieder runterfallen« - 
diese Weisheit ist bei »Fast Freddie« unverkennbar. 
М 


90 Schiebung A 


Zugegeben - das Spielprinzip ist nicht gerade neu. 
Aber lassen Sie sich von dieser gelungenen und 
reizvollen Umsetzung überraschen. 


97 Zwilling gesucht EI 


Sie haben ein gutes Gedächtnis? »Memory« wird Sie 
testen. 


Statten Sie Ihr 
Spiel mit der 
richtigen Theorie 
aus - denn Erfolg 
ist kein Roulette- 
spiel 


SEITE 44 


| NHALT 


107 Krieg den Kernen Ы 


»Reaktor« ist ein exzellentes Strategiespiel. Lösen Sie 
die Kettenreaktion aus, die Ihren Gegner vernichtet. 
Aber Vorsicht - er hat die Chance, sich zu rächen. 


ET eem Fre 


Mit diesem IFF-Lademodul von Fridtjof Siebert laden 
Sie Ihre Grafiken problemlos und schnell. 


121 Packen wire an EN 


Grafiken brauchen viel Platz und ebensoviel Zeit 
zum Laden. Abhilfe schafft ein guter IFF-Packer. 


122 Der gute Ton zum Spiel 
Eine »Ohrenweide« programmieren Sie mit diesen 
Soundmodulen in Modula-2. 


FAST FREDDIE 


»Fast Freddie« - das Spiel für Auf- 
und Absteiger, Umsteiger und Überflieger SEITE 88 


133 Der Standard 


Electronic Arts setzte mit dem Interchange File 
Format einen Standard zum Austausch von Daten. 
Hier finden Sie alles, was Sie w wissen müssen. 


135 P und kein Ende 


Spiele sind das Thema für einen Computer wie 
den Amiga. Welche Sorten sind auf dem Markt? 
Lassen sich diese in Kategorien einteilen? 


136 Von der Idee zum Erfolg 


Vermarktungsstrategien für kommerzielle Spiele 
sind ein heiBes Eisen. Martin Jobst hat Tips von 
erfahrenen койа gesammelt. 


3 Editoria 
138 Aus unserem Bücherregal 
146 Impressum 


Alle Programme aus Artikeln mit einem ` -symboı finden Sie auch auf der Programm- 
service-Diskette zu diesem Sonderheft 


Projektentwicklung 


Am Anfang 
ar die Idee 


Wir zeigen Ihnen 
anhand eines Beispiels, wie man 
eine Spielidee in die 
Wirklichkeit, sprich in ein 
Programm, umsetzt. 


Von Arno Gölzer 


eht es Ihnen nicht auch 
manchmal so? Man 
sitzt im Zug, geht spa- 


zieren oder liest gerade das 
neue Sonderheft und plötzlich - 
eine Idee! Eine Idee für ein neu- 
es Amiga-Spiel. Noch bevor 
das Computerzimmer, etwas 
auBer Atem, erreicht ist, ist das 
Spiel schon deutlich vor Augen, 
doch kaum ist der Editor gela- 
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den, findet man keinen Anfang. 
Warum eigentlich? 

Das Bild vor Augen ist das 
Wunschbild eines Spiels, man 
stellt es sich selbstverständlich 
mit der tollsten, blitzschnell ani- 
mierten Grafik und einem Su- 
per-Stereosound vor. Wer jetzt 
in seinem Enthusiasmus plan- 
los vorgeht, wird von der Pro- 
blematik, die bei der Realisie- 
rung eines Spiels auftritt, förm- 
lich erschlagen. Was jetzt fehlt 
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P ROJEKT 


ist ein Konzept, welches das 
Problem der Realisierung in 
viele kleine, leicht überschau- 
bare Teilprobleme zerlegt. Zu- 
nächst sollten Sie Ihre Idee ver- 
balisieren und niederschrei- 
ben. 

Bereits bei dieser Fixierung 
zerlegen Sie das Programm 
mehr oder weniger bewußt in 
Teilbereiche. Manchmal wissen 
Sie bereits, wie sich ein solcher 
Teilbereich in Ihre Lieblingspro- 


= 


tr AA AAA MAMAA NAA tetris tire 


grammiersprache umsetzen 
läßt. Notieren Sie sich die Lö- 
sung sofort und verweisen Sie 
im Text darauf. Stecken Sie Ihre 
Ziele ruhig hoch und nehmen 
Sie während der Beschreibung 
eines Bereichs keine Wertung 
vor! Killerphrasen, wie etwa 
»das schaffe ich nie« oder »kein 
Mensch würde das so machen«, 
sind verboten! 

Halten Sie auch Ideen für Ex- 
tras fest, die nichts mit dem ei- 


gentlichen Spiel zu tun haben, 
wie zum Beispiel ein Modus für 
mehrere Spieler oder einen 
Entwurf für ein Titelbild. Sie 
werden feststellen, daß Sie 
nach dieser Beschreibung eine 
viel bessere Vorstellung von Ih- 
rem Spiel bekommen werden. 
Neue Ideen fließen Ihnen zu, 
Sie inspirieren sich selbst. Ein- 
zelne Funktionen lassen sich 
bereits umsetzen, andere kann 
man zumindest, (vielleicht mit 


7 


Flußdiagrammen), näher um- 
schreiben. 

Bald wird eine erste spielbare 
Version Ihres selbstprogram- 
mierten Spiels fertiggestellt 
sein. Diese wird dann verbes- 
sert und ausgeschmückt, bis 
das Programm Ihren Vorstellun- 
gen entspricht. Vielleicht sieht 
Ihr Projekt jetzt anders aus als 
zu Beginn vor dem geistigen 
Auge, aber - und das ist ent- 
scheidend - jetzt ist es reall 
Was hier in wenigen Zeilen be- 
schrieben ist, dauert in Wirk- 
lichkeit natürlich einige Wo- 
chen und Monate, manchmal 
sogar Jahre. Wen wundert da 
der Groll der Programmierer 
gegen Raubkopierer, die sorglos 
die Früchte langer und harter 
Programmierarbeit verteilen... 

Lassen Sie uns im Zeitraffer 
die Entwicklung eines Spiels 
am Beispiel Reflex nachvollzie- 
hen. Eine erste Beschreibung 
des Gedankenspiels könnte 
wie der Text im untenstehenden 
Kästchen formuliert sein - die 
Randnotizen sind in Klammern 
gesetzt. 

Obwohl diese sehr kurze Be- 
schreibung den Kern des 
Spiels nur grob beschreibt, las- 
sen sich einige wichtige Infor- 
mationen ablesen. Z.B., daß 
der Screen für Sprites vorberei- 
tet sein muß. Ein erster Ansatz- 
punkt - wir beginnen mit dem 
Screen. 

Überlegung: Erstellen wir 
über View ein eigenes Display 
oder nutzen wir einen Intuition- 
Screen? Der Text gibt Auskunft. 
Reflex erwartet viele Reaktio- 
nen vom Spieler, z. B. die Bewe- 
gung der Kanone oder Hinder- 
nisse drehen. Diese sind sehr 
einfach über das von Intuition 
zur Verfügung gestellte Mes- 
sage-System abzufragen. Dar- 
über hinaus ist ein High-Score- 
Window gefordert. Wir brau- 
chen Intuition also ohnehin, 
wenn wir den Programmierauf- 
wand gering halten wollen. Und 
nicht zuletzt: Wir können uns 


den »Verlust« des für Intuition 
notwendigen Speichers leisten, 
denn nach der Beschreibung 
dürfte Reflex auch auf einem 
Amiga mit der Grundversion 
von 512 KByte Arbeitsspeicher 
problemlos laufen. Also nutzen 
wir die einfache Handhabung 
der Intuitionroutinen und daher 
auch einen Intuition-Screen. Ei- 
ne hohe Auflósung ist nicht un- 
bedingt nótig, wir definieren ei- 
nen Lores-Screen mit schát- 
zungsweise acht oder besser 
gleich 16 Farben. Falls noch 
mehr Farben nótig sind, ist das 
schnell geándert. 


struct NewScreen nser- 
[/x neuer LoRes- 
Sereen x/ 
0,0,320,256,4,0,0, 
SPRITES, CUSTOMSCREEN , 
NULL, NULL, NULL, NULL 

E 

Bevor wir den neuen Screen 
öffnen, muß die Basisadresse 
der Intuition-Library bekannt 
sein. Das beste wird es sein, 
wenn wir alle diese Vorbereitun- 
gen (wie das Öffnen der Libra- 
ries, des Screens und der Win- 
dows etc.) in einer Funktion zu- 
sammenfassen: OpenW() (Li- 
sting 1) für »Open Work«. 

Dies ist eine wichtige Infor- 
mation, die wir während der ge- 
samten Entwicklungszeit für 
Reflex im Auge behalten müs- 
sen - gleich notieren! 


Notiz: Vorbereitende Funk- 


tionsaufrufe in der Funktion 
OpenW() einordnen! 


Apropos Windows - wie viele 
Fenster brauchen wir eigent- 
lich? Laut Text sind es minde- 
stens zwei: ein Spielfeld mit Be- 
dienungselementen und ein 
High-Score-Window. 

Überlegung: Der Spieler hat 
mit der geforderten Hilfsfunk- 
tion die Möglichkeit, Linien auf 
das Spielfeld zu zeichnen. Bei 
der Verwendung eines eigenen 


Erste Beschreibung vom 1.6.1989 


Eine Kugel (Sprite) wird aus einer in X-Richtung beweglichen Kano- 
ne (Sprite, mit der Maus anklicken und bewegen) abgefeuert. Vor dem 
Ziel sind drehbare Hindernisse (Linien im COMPLEMENT-Modus ge- 
zeichnet) angebracht. Die Kugel soll in einer Art Kettenreaktion an 
móglichst vielen Hindernissen abprallen und dann ihr Ziel finden (An- 
zahl der getroffenen Hindernisse in die Bewertung eingehen lassen). 


Extras: 


- Geráusche, z.B. beim Abprallen der Kugel an einem Hindernis 


(übernimmt Gólzys »SEEd«) 


- 2-Spieler-Option (umschalten über Gadgets) 

- jederzeit einsehbare High-Score-Liste (eigenes Window) 

- Hilfsfunktion, die zeigt, wie die Kugel an einer Barriere reflektiert 
wird (Linien im COMPLEMENT-Modus, gleiche Berechnung wie bei 


Kollision der Kugel) 


Windows für das Spielfeld müs- 
sen wir hierbei nicht testen, ob 
Sich eine Linie bereits auBer- 
halb des Spielfeldes befindet, 
um sie dort zu »kappen«. Das 
übernimmt in diesem Fall das 
Betriebssystem für uns. Grund 
genug, um Spiel- und Bedie- 
nungsfeld zu trennen. Dem- 
nach benötigen wir vorläufig 
drei Windows. Widmen wir uns 
als erstes dem Spielfeld-Win- 
dow (und schon ist wieder eine 
Aufgabe zerteilt!). Wir nutzen 
die gesamte Höhe des Screens. 
Wir möchten ein optisch an- 
sprechendes quadratisches 
Spielfeld. Somit haben wir auch 
die Breite des Windows: Höhe 
=Breite=256 Pixel. 

struct NewWindow pwin= 
[/x Spielfeld x/0,0,256, 
256,0,1, MOUSEBUTTONS, 
RMBTRAP,NULL,NULL,NULL, 
NULL,NULL,0,0,0,0, 
CUSTOMSCREEN 

Ve 

)? 

Das Window wird in OpenW() 
geóffnet. Vereinbaren wir doch 
gleich die Umkehrfunktion Clo- 
seW() (Listing 2). Darin schlie- 
Ben wir alle vom Betriebssy- 
stem angeforderten Quellen in 
umgekehrter Reihenfolge. Nach 
der Definition der GetMessage- 
Funktion, mit deren Hilfe wir die 
Intuition-Nachrichten empfan- 
gen, kónnen wir einen Probe- 
start wagen: 
/xReflex-Version 0.01x/ 


VOID main() 
f 

t 

ULONG class; 
BOOL Quit=0; 
Орепи(); 
while(!Quit) 
( 


t 

Wait(1«Play—>UserPort- 
>mp_SigBit); 

while(class=GetMessage 
(DWin,0,0)) 

f 

t 

Quit=1; 

| 

| 


! 
CloseW(); 
| 
J 
In jeder Testversion wird die 
Versionsnummer erhöht und 
vermerkt. Kleine Änderungen 
erhöhen die Nummer im Hun- 
dertstelbereich, der Abschluß 
eines großen Teilgebiets im 
Zehntelbereich. Doch nach er- 
folgreicher Übersetzung, end- 
lich der erste Probestart. 
Enttäuscht wird man feststel- 
len: Vom Window sieht man nur 
den Rahmen, und für das Be- 


dienungsfeld bleibt daneben 
recht wenig Platz. Etwa ein 
Viertel der Screenbreite sollte 
das Bedienungsfeld schon 
messen. Das Beste ist es, beide 
Fenster gleich zu óffnen und 
dann deren Breite und Position 
zu optimieren. Eine Zeichnung 
auf kariertem Papier erleichtert 
diese Arbeit erheblich. Stim- 
men Position und Dimension 
der beiden Windows, erfolgt die 
Farbgebung. Auch sie ordnen 
wir in einer eigenen Funktion 
ein, denn nichts ándert man in 
einem Programm öfter als die 
Farben, Jetzt kónnen die bisher 
leeren Window-Rahmen nach 
eigenem Geschmack gestaltet 
werden. Hierzu sind Grafik- 
funktionen und damit die Basis- 
adresse der Graphics-Library 
nótig. Wir ergánzen OpenW( ) 
und CloseW() entsprechend. 


. Der Aufbau des Reflex-Bild- 


schirms übernimmt Draw- 
Screen(). Das Spielfeld wird 
komplett: weiß gefärbt und er- 
hált einen einfarbigen dunklen 
Rahmen. An diesem Rahmen 
wird spáter der Kugelsprite re- 
flektieren, der somit innerhalb 
der Spielfeldgrenzen bleibt. 
Das Bedienungsfeld fárben wir 
dunkel mit einem hellen Rand 
links oben und einem dunklen 
Rand rechts unten. Damit er- 
scheint das Feld reliefartig und 
von einer Lampe erhellt. Ver- 
schiedene Rahmen und die 
Schriften POut() (Listing 3) (er- 
scheint aufgesetzt) und Pln() 
(Listing 3) (erscheint einge- 
prágt) verstárken den plasti- 
schen Eindruck. 

Wichtig für das Gesamtbild 
ist, immer die Position der ima- 
gináren Lichtquelle im Auge zu 
behalten und die Farben der 
Rahmen, der Schriften oder an- 
derer Bildschirmobjekte ent- 
sprechend zu setzen. Ein er- 
neuter Testlauf stellt das ver- 
wohnte Programmiererauge 
schon eher zufrieden. Die neue 
Version ist es sicher wert, zur 
Entspannung erst einmal Kaf- 
fee aufzusetzen und das Pro- 
gramm neben der Arbeitsdis- 
kette auch auf einer anderen 
Diskette in einem eigenen Ver- 
zeichnis als Sicherheitskopie 
»zu verewigen«. Manchem wird 
dieser Aufwand als übertrieben 
erscheinen. Aber glauben Sie 
mir, wenn ich behaupte, daB 
sich dieser Aufwand lohnt. 
Denn wenn sich, aus welchen 
Gründen auch immer, Ihr Ami- 
ga dazu entschlieBt, Ihre Ar- 
beitsdiskette nach eigenen Vor- 
stellungen zu gestalten, haben 
Sie das Nachsehen. Nachdem 
der Kaffee endlich durchgelau- 
fen ist, kann es mit der Gestal- 
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tung des Spielfeldes weiterge- 
hen. Hier ist folgendes vorge- 
geben: 

a) Eine Kanone soll in X-Rich- 
tung beweglich sein. Wir brin- 
gen die Kanone am unteren 
Spielfeldrand an. Die Schuß- 
richtung ist daher senkrecht 
nach oben. 

b) Ein Ziel muß sichtbar sein. 
Natürlich möchten wir kein 
Kampfspiel programmieren, 
dessen Spielziel es ist, mög- 
lichst viele kleine Männchen 
(oder Frauchen) abzuschießen. 
Ganz im Gegenteil: Das Ziel 
soll eine einfache Höhle oder 
Grube sein, in der der Spieler 
die Kugel versenken muß, be- 
vor sie durch eine Explosion 
Schaden anrichten kann. 

c) Hindernisse oder Barrieren 
sollen das Ziel versperren. 

Sie sehen, die Teilaufgaben 
werden kleiner und damit auch 
leichter überschaubar. Sie las- 
sen sich so schnell und einfach 
erledigen, was durchaus moti- 
vierend wirkt. Wir arbeiten uns 
von vorne her durch: Punkt a) 
bereitet fast keine Probleme. 
Die Kanone ist mit einem Spri- 
teeditor oder auf einem karier- 
ten Blatt Papier schnell entwor- 
fen. Wenn wir gerade dabei 
sind, können wir auch gleich 
die Kugel entwerfen. Es fehlt 
dann nur noch die Routine, wel- 
che die Kanone bei einem 
Mausklick an den Pointer 
»klebt«. MoveK( ) (Listing 4) er- 
ledigt das für uns. Hier zeich- 
nen wir auch eine »Starige«, auf 
der die Kanone befestigt ist. 

Bevor es-weitergeht, schnell 
noch ein geistiger Probelauf: 

An der Unterkante des Spiel- 
felds ist eine Stange ange- 
bracht. Darauf ist eine Kanone, 
in Stangenrichtung verschiebbar 
montiert. Linke Maustaste drük- 
ken... Kanone positionieren... 
Klick links und Schuß. Mist! 

Beim Klick hat sich kein 
Schuß gelöst, sondern die Ka- 
none hat sich bewegt! 


Notiz: Schuß auslösen mit 
rechter Maustaste. 


Noch ein Probelauf in Ge- 
danken: Linke Maustaste 
drücken... Kanone positionie- 
ren... Klick rechts und Schuß. 
Jaaa! Man sieht die Kugel förm- 
lich fliegen. Sie erreicht den 
oberen Bildschirmrand... re- 
flektiert dort... kommt zu- 
rück... und trifft die Капопе!!! 


Notiz: Kanone mittels einer 
Linie in der Farbe des Spiel- 


feldrandes vom Spielfeld 
trennen. 
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Ein letzter Testflug zeigt, daß 
die Kugel sowohl am oberen 
Rand als auch an der Trennlinie 
abprallt. Nach entsprechenden 
Änderungen und Ergänzungen 
zeigt ein realer Probelauf, daß 
wir die while-Schleife in main() 
noch abändern müssen, denn 
gleich nach einem Mausklick 
endet Reflex in dieser Version. 
In OpenW() erhalten verschie- 
dene Variablen die Signalbits 
der einzelnen Windows. Mittels 
Wait() erkennen wir, welches 
Window Nachrichten sendet. In 
der momentanen Version 0.04 
beenden wir das Programm, 
sobald das Bedienungs-Win- 
dow eine Nachricht liefert. Wei- 
ter geht es laut Plan mit Punkt 
b): Es geht um das Ziel. Sehr 
einfach, am oberen Rand des 
Spielfeldes zeichnen wir mittig 
ein Loch als Ziel. In der Höhe 
richten wir uns nach dem am 
unteren Bildschirmrand abge- 
teilten Kanonenbereich, um ei- 
nen einigermaßen symmetri- 
schen Bildschirmaufbau zu er- 
reichen. Allerdings wird das 
Loch dann ziemlich klein und 
daher nicht einfach zu treffen. 
Was tun? Reflex soll ja nicht fru- 
strierend, sondern entspan- 
nend wirken. 

Klar! Wir zeichnen Löcher 
am besten gleich drei Stück. 

Die Funktion DrawHole() (Li- 
sting 5) zeichnet ein Loch an 
der als Parameter gelieferten X- 
Position, so daß sich die Anzahl 
noch variieren läßt. 

Geistiger Testflug: Kanone 
bewegen... Schuß... Treffer! 


. Das Ziel wurde vor der Detona- 


tion der Kugel erreicht! Schade 
jedoch, daß die Explosion nicht 
zu sehen war. Von solchen klei- 
nen Effekten »lebt« aber ein 
Spiel. Wir richten DrawHole( ) 
So ein, daf sie bei Bedarf auch 
ein »von innen erhelltes« Loch 
zeichnen kann. Ein abwech- 
selndes Aufrufen der Funktion 
im Normal- und im Flushmodus 
erweckt den Eindruck einer un- 
terirdischen Explosion, deren 
Blitze man durch die Hóhlenóff- 
nung sehen kann. 


Notiz: Bei Treffer Explosion 
Sichtbar machen, Soundef- 


fekte kónnten den Eindruck 
noch unterstützen. 


Es fehlt noch Punkt c). Die 
Spielfeldmitte ist in ihrer gan- 
zen Breite frei für Barrieren. In 
der Projekt-Beschreibung (im 
Kasten) finden wir für die Hin- 
dernisse den Hinweis »Linien 
im COMPLEMENT-Modus ge- 
zeichnet«. Also los: Wenn wir 
für eine Linie eine Breite von 30 
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Pixel annehmen und dabei be- 
rücksichtigen, daß der Spieler 
jede dieser Linien um den Mit- 
telpunkt drehen kann, errech- 
nen wir, daß auf dem Feld 42 
Barrieren in sechs Reihen Platz 
finden. Eine Schleife in Draw- 
Ріау() (Listing 6) zeichnet uns 
die Hindernisse ein, und die Init- 
Сук )-Funktion (Listing 7) sorgt 
für eine neue Ausgangsstel- 
lung der Barrieren. Ein Probe- 
start zeigt, daß das Spielfeld 
trotz der vielen Striche leer und 
wenig ansprechend wirkt. Also 
montieren wir die Hindernisse 
auf einzelne Sockel. Da die Li- 
nien spáter um ihren Mittel- 
punkt kreisfórmig beweglich 
sind, wáhlen wir eine zylindri- 
sche Form. Bei der Konstruk- 
tion der Sockel berücksichtigen 
wir wieder die imagináre Lam- 
pe in der linken oberen Screen- 
Ecke. Somit ist das Spielfeld 
schon fertig aufgebaut. Ein 
Manko hat es allerdings noch: 
Das Zeichnen der 42 Zylinder 
mit Barrieren dauert zu lange. 
Ein kleiner Kunstgriff erspart 
dem Spieler die Wartezeit: Wir 
zeichnen den Zylinder nur ein 
einziges Mal auf einen ver- 
steckten RastPort und kopieren 
ihn dann mittels einer Blitter- 
funktion auf das Spielfeld. 

MakeOyl( ) (Listing 8) zeich- 
net einen roten und einen gel- 
ben Zylinder für Explosionen 
auf den RastPort eines Hilfs- 
windows. Die Funktion Draw- 
Cyl( ) (Listing 9) clippt die Grafik 
dann an die gewünschte Stelle 
im Spielfeld. Der Aufruf des neu 
übersetzten Programms bestä- 
tigt: Das Feld ist in einem 
Bruchteil einer Sekunde aufge- 
baut. Das Zeichnen der Barrie- 
ren im COMPLEMENT-Modus 
übernimmt ebenfalls Draw- 
Cyl( ), allerdings indirekt, durch 
den Aufruf der Funktion Draw- 
Bar( ) (Listing 10). Um eine Bar- 
riere an der richtigen Position, 
in der richtigen GróBe und im 
richtigen Winkel zeichnen zu 
kónnen, benótigen wir die ent- 
sprechenden Daten für jede 
Barriere. Wir fassen sie, der 
Übersichtlichkeit wegen, in ei- 
ner Struktur zusammen. So 
sollte man mit zusammengehó- 
renden Daten immer verfahren. 
Dazu gehórt natürlich die Be- 
Schreibung der einzelnen Da- 
ten in Form eines Kommentars. 

Nur kommentierte Quellco- 
des lassen sich auch nach ei- 
nem längeren Zeitraum noch 
problemlos lesen! 

Nach der gewohnten Sicher- 
heitskopie haben wir innerhalb 
unserer Programmentwicklung 
einen gróBeren Bereich, sprich 
den Spielfeldaufbau, abge- 


schlossen - Grund genug, um 
die Versionsnummer auf 0.10 zu 
erhóhen. Womit geht es weiter? 
Stellen wir die verbleibenden 
Teilbereiche gegenüber und 
werten sie aus: 

Ist es sinnvoll, mit der High- 
Score-Liste zu beginnen? Si- 
cher nicht, wir könnten sie zwar 
anlegen, aber nicht testen, da 
Reflex noch keine Punkte er- 
rechnen kann. Sollten wir uns 
dem Bedienungsfeld widmen? 
Auch hier fehlen zu viele Infor- 
mationen. Also bleiben wir 
beim Spielfeld und kümmern 
uns um die dort fehlenden 
Funktionen. Für das weitere 
Vorgehen stellen wir uns wieder 
einen Plan auf: 

a) Das Einstellen der Hindernis- 
se ermóglichen 

b) Kugelsprite bewegen = 
Schuß 

c) Kollisionsabfrage und Reak- 
tion an Hindernis und Spielfeld- 
rand 

d) Bewertung, Punktevergabe 

Bei der Aufstellung einer sol- 

chen Liste sollte man gleich auf 
eine logische Reihenfolge ach- 
ten. Verständlicherweise muß 
vor der Formulierung der Kolli- 
sionsabfrage die Kugel beweg- 
lich sein, um diese auch testen 
zu können. Steht die Liste, so 
verfährt man wie gewohnt. Das 
erste Problem aufgreifen und 
zerlegen: 
a) die Drehung der Hindernisse 
soll mit der Maus erfolgen. 
Nichts ist für den Benutzer ei- 
nes Programms ärgerlicher, als 
ständig zwischen Maus und Ta- 
statur wechseln zu müssen. Da 
beide Maustasten bereits mit 
»Kanonenfunktionen« belegt 
sind, bleiben uns für die Aus- 
wertung zwei Möglichkeiten: 
Entweder wir lassen den Spie- 
ler über ein Modify-Gadget mit- 
teilen, daß er die Barrieren dre- 
hen möchte, oder wir unter- 
scheiden räumlich zwischen 
dem Bereich, in dem die Kano- 
nen beweglich sind, und dem 
eigentlichen Spielbereich. 

Die erste Methode ist für uns 
als Programmierer einfacher. 
Ist das Modify-Gadget selek- 
tiert und die linke Maustaste ge- 
drückt, wissen wir, daß der 
Spieler den Winkel einer Bar- 
riere ändern möchte. Jedoch ist 
es für den Spieler umständlich, 
während des Spiels ständig 
Einstellungen vornehmen zu 
müssen. Also unterscheiden 
wir in der Funktion CheckMou- 
se() (Listing 11) zwischen 
Kanonen- und Spielbereich. 
Außerdem prüfen wir dort, ob 
die linke oder die rechte Mau- 
staste betätigt wurde. Wir unter- 
scheiden vier mögliche Fälle: 
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1) Linke Taste, Kanonenbe- 
reich: Kanone bewegen 
2) Rechte Taste, Kanonenbe- 
reich: Kanone abschießen 
3) Linke Taste, Spielbereich: 
Hindernis drehen 
4) Rechte Taste, Spielbereich: 
Hat vorerst keine Funktion. 
Eine Funktion haben wir 
noch frei. Die Hilfsfunktion 
könnte hier gut passen. Stellen 
Sie sich vor, Sie richten gerade 
mit der linken Taste eine Barrie- 
re aus und können mit der rech- 
ten Taste gleich überprüfen, ob 
der Winkel in etwa stimmt. 


Notiz: Rechte Maustaste im 


Spielbereich für Hilfsfunk- 
tion reservieren. 


Sofort wird die Realisierung 
der Hilfsfunktion in unseren 
neu aufgestellten Plan über die 
weitere Vorgehensweise unter 
e) aufgenommen. Stellen wir 
die Betätigung der linken Maus- 
taste im Spielbereich fest, rufen 
wir die Funktion TurnBar( ) (Li- 
sting 12) auf, welche den Win- 
kel errechnet und das Hinder- 
nis, durch den Aufruf von Draw- 
Bar( ), neu darstellt. Ein Testlauf 
zeigt uns eine Besonderheit: 
Klickt man auf den Drehpunkt 
der Linie, wird diese aufgrund 
der Berechnung als Punkt dar- 
gestellt! Eine Besonderheit, die 
besonders der Anfánger gerne 
nutzen wird, da er aus der Viel- 
falt der Hindernisse einige ge- 
zielt »ausschalten« kann. Man 
kónnte sie sogar noch etwas 
ausbauen, indem man Funktio- 
nen zur Verfügung stellt, die 
ganze Hindernis-Spalten und 
-Reihen ausschalten. 


Notiz: Funktionen zum Aus- 
schalten von Hindernissen 


zur Verfügung stellen. 


Sie sehen, wáhrend der Pro- 
grammentwicklung ergeben 
sich völlig neue Ideen, die das 
Spiel bereichern können. Wir 
kommen zur Realisierung von 
Punkt b) unserer Liste. Die Spri- 
tedaten der Kugel liegen uns 
bereits vor, hier haben wir ja 
schon Vorarbeit geleistet. So- 
bald uns Intuition im Kanonen- 
bereich die Betätigung der 
rechten Maustaste meldet, ver- 
zweigen wir nach Schuss(). 
Diese Funktion übernimmt alle 
notwendigen Voreinstellungen 
für das Bewegen der Kugel. Die 
eigentliche Bewegung über- 
nimmt MoveK(), indem die 
Funktion zur aktuellen Sprite- 
position Geschwindigkeitsvek- 
toren in X- und Y-Richtung ad- 
diert. Zu Beginn ist der X-Vektor 


10 


gleich null und der Y-Vektor ne- 
gativ. Daraus resultiert eine Ku- 
gelbewegung nach oben. 


Notiz: Eine Veränderung 
der Vektoren bewirkt einen 
Richtungswechsel (wichtig 


für die Reaktion nach der 
Kollision mit einem Hinder- 
nis oder dem Spielfeldrand). 


Schnell mal übersetzen und 
einen Probestart wagen! Das 
Drehen der Hindernisse sieht 
nicht übel aus. Aber jetzt auf 
zum ersten Schuß: 

Kanone positioniert... rechte 
Maustaste gedrückt, und schon 
fliegt die Kugel los - SUPER!... 
sie reflektiert am Rand oben... 
am Rand unten... und fliegt 
und reflektiert und fliegt und... 
und hórt gar nicht mehr auf! 

Natürlich: Die Verlangsa- 
mung und schlieBlich den Still- 
stand der Kugel müssen wir 
auch noch eingeben. Jetzt hilft 
nur noch ein Reset, um das 
Programm zu beenden. Das 
schnelle Übersetzen zwischen- 
durch hat sich zeitlich nicht ge- 
lohnt! Wir ergánzen MoveK() 
durch einige Zeilen, welche 
durch die stándige Verminde- 
rung der Geschwindigkeitsvek- 
toren die Kugel verlangsamen. 
Unter einem bestimmten Wert 
setzen wir die Vektoren gleich 0 
- die Kugel bewegt sich nicht 
mehr - hier endet der mißglück- 
te Versuch, das Ziel zu treffen. 

Diese Stelle markieren wir 
uns im Listing, da hier noch ei- 
ne entsprechende Reaktion fol- 
gen muB. Wie müßte diese Re- 
aktion aussehen? Wir haben 
festgelegt, daß die Kugel das 
Zielloch erreichen muB, bevor 
sie Schaden anrichtet. Das 
heißt, sie muß in diesem Fall, da 
das Ziel nicht erreicht wurde, et- 
was anrichten. Wir setzen zu 
Testzwecken einfach ein Dis- 
playBeep() ein. 


Notiz: Das Ziel wurde nicht 
erreicht: Lóschen der Kugel 
und Zerstórung einiger Zy- 
linder - der Spieler kann im- 
mer weniger Punkte errei- 


chen, da die Zahl der Hin- 
dernisse abnimmt - daraus 
folgt: Spielende nach Ver- 
lust des letzten Zylinders. 


Das bringt uns auch gleich 
zu dem náchsten Punkt: die Ab- 
frage unserer Ziele. Befindet 
sich die Kugel im Bereich der 
Lócher am oberen Spielfeld- 
rand, kontrollieren wir innerhalb 
MoveK( ), mittels eines Aufrufs 
der CheckH( )-Funktion (Listing 


13), ob sich der Kugelsprite 
über einer Farbe befindet, die 
für das Zeichnen der Lócher 
benutzt wurde. Ist dies der Fall, 
leitet CheckH() die Kugel ins 
Zentrum des Lochs, um sie dort 
zu lóschen - was für den Spie- 
ler wie ein Fallen der Kugel in 
ein tiefes Loch aussieht. 

Ein Blick in unsere Notizen 
erinnert uns: Hier ist eine (un- 
terirdische) Explosion vorgese- 
hen. Die for-Schleife innerhalb 
CheckH() erzeugt sie - das 
Loch wird so gezeichnet, als sei 
es durch Blitze erleuchtet. Der 
Vermerk wird nur teilweise ge- 
strichen, er enthált noch die An- 
regung »Soundeffekt«. 

Damit kónnen wir Punkt b) 
unserer Liste abschlieBen und 
uns auf die Kollisionsabfrage, 
Punkt c), konzentrieren. Wir 
müssen, um den Lauf der Kugel 
genau kontrollieren zu kónnen, 


vor jeder Bewegung der Kugel ` 


prüfen, ob sich an der neuen 
Kugel-Position ein Hindernis 
oder der Feldrand befindet. Der 
Funktionsaufruf CheckB( ) (Li- 
sting 14) ist hierfür vorgesehen. 
Dort erfolgt auch die Neube- 
rechnung der Geschwindig- 
keitsvektoren, die ja laut Notiz 
die Richtung der Kugel ändert. 
Jetzt dürfte bei einem erneuten 
Probelauf nichts mehr schief- 
gehen. Die Kugel sollte am 
Feldrand und an den Hindernis- 
sen korrekt reflektieren. Sie 
müßte ständig langsamer wer- 
den und schließlich mit einem 
Flush (DisplayBeep()) oder, 
falls der Schuß gut war, mit ei- 
ner Explosion in einem der Ló- 
cher verschwinden. Mal sehen 
.. zuerst jedoch eine Sicher- 
heitskopie. Und frischen Kaffee 
aufsetzen. Ein Test der neue- 
sten Reflex-Version zeigt noch 
einige Fehler auf, aber auch 
das gehórt zum Programmierer- 
alltag und láBt uns vóllig cool 
bleiben. Wir wissen ja, in wel- 
chen Routinen der Fehler 
steckt, und nach einiger Zeit 
kann erneut compiliert werden. 
Danach ist auch der Kaffee fer- 
tig, und einem erneuten Test 
steht nichts mehr im Wege. 

Diesmal läuft das Programm 
fehlerfrei, zumindest рго- 
grammtechnisch. Aber ein 
ganz anderer »Fehler« macht 
sich bemerkbar: Hat man ein- 
mal beim Spielen eine gute Ein- 
stellung der Hindernisse gefun- 
den und die Kanone richtig po- 
sitioniert, könnte man beliebig 
viele Punkte machen und sämt- 
liche High-Score-Listen spren- 
gen, indem man nichts an der 
erprobten Einstellung ändert 
und immer wieder von dersel- 
ben Stelle aus feuert. 


Auch daran muß man sich 
gewöhnen. Manchmal treten 
Situationen auf, mit denen man 
vorher nicht gerechnet hatte. 
An solchen Stellen darf man die 
Flinte nicht ins Korn werfen. 
Wenn sich in einer verfahrenen 
Situation scheinbar keine Lö- 
sung anbietet, schalten Sie den 
Rechner aus und versuchen es 
am nächsten Tag erneut. Sie 
werden dann sicher eine an- 
nehmbare Lösung dafür finden. 
Wie sieht die Lösung für unser 
Problem aus? 

Man könnte die Stellung der 
Hindernisse oder der Kanone 
nach jedem Schuß verändern, 
das wäre jedoch sicher nicht 
die Lösung, um den Spieler an 
den Bildschirm zu fesseln. Es 
gibt (mindestens) eine andere 
Lösung: Die Kugel soll »unter 
der Wucht des Aufpralls« das 
erste Hindernis zerstören, und 
schon ist die ganze schöne Ein- 
stellung dahin - schade, scha- 
de, schade! 

Natürlich muß diese Explo- 
sion zu sehen sein. Wir stellen 
den Zylinder gelb dar, warten 
kurz und löschen ihn mit der 
Funktion КІШСУ() (Listing 15). 
In einer vierfach verschachtel- 
ten Schleife lassen wir die 
»Trümmer« kreisförmig vom Ex- 
plosionsherd davonstreben. 
Die Daten für die Explosion be- 
rechnen wir aus Gründen der 
Ausführungsgeschwindkeit in 
InitData( ) (Listing 16) vor. Ein 
Test zeigt uns, daß zwar die Ex- 
plosion recht gut aussieht, aber 
das Spiel in der Zeit, in der sie 
abläuft, stillsteht. Glücklicher- 
weise ist der Amiga multitask- 
ingfähig. Das ist die Lösung! 
Spiel und Explosion lassen sich 
durch den Start eines eigenen 
Prozesses, mit Hilfe der Funk- 
tion CreateFunctionProc( ), 
scheinbar gleichzeitig abarbei- 
ten. Die ProzeB-Funktion, sie 
heiBt TFunc() (Listing 17), ist 
zur Verdeutlichung des Sub- 
Prozesses als einzige Funktion 
hinter main() angeordnet. Die 
Kommunikation mit dem Sub- 
ProzeB findet über den unbe- 
nutzten User-Port des Hilfswin- 
dows statt. Empfángt der Pro- 
zeß die Nachricht FIRSTCOLLI- 
SION, so startet er die Explo- 
sion. Wenn Sie sich über diese 
Technik genauer informieren 
wollen, empfehlen wir entweder 
ein genaues Studium des Li- 
stings oder einen Blick in das 
nächste AMIGA-Magazin, das 
Ende Oktober am Kiosk liegt. 
Sie finden dort einen Artikel, 
der ausführlich auf dieses The- 
ma eingeht. Kónnte man diese 
Explosion nicht auch zur Elimi- 
nierung der drei Zylinder beim 
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Nichterreichen des Ziels einset- 
zen? Das ist sicher möglich, 
würde aber sicher mit der Zeit 
langweilig wirken. Da muß eine 
neue Idee her. Die Lösung: Die 
Zylinder zerbröckeln durch den 
Druck der Explosion. 

RectFill) füllt den Bereich 
der drei nähesten Zylinder, die 
wir mit GetCyINr() (Listing 18) 
ermitteln, mit kleinen Recht- 
ecken in der Farbe des Spielfel- 
des aus. Die Positionen der 
Rechtecke sollen zufállig ver- 
teilt sein. Die Ermittlung der Zu- 
fallszahlen (wir benötigen 
gleich 500 Stück!) dauert natür- 
lich wieder einige Zeit, so daß 
das Füllen sehr langsam ge- 
schieht. Also müssen wir die 
Zufallszahlen vorberechnen. 
Eine weitere Aufgabe für InitDa- 
ta(). Nach einem sehr ausge- 
dehnten Punkt c) soll laut unse- 
rer Liste die Umsetzung der Be- 
wertung eines Versuchs folgen. 
Dies ist eine einfache Aufgabe: 
Eine globale Variable wird bei 
jeder Kollision mit einem Hin- 
dernis um eins inkrementiert. 
Wurde die Kugel versenkt, er- 
rechnet sich die Punktzahl in 
CheckH( ) aus dem Produkt der 
Kollisionsanzahl und der Punk- 
te für das Zielloch. Das mittlere 
Loch wird mit zehn und die äu- 
Beren mit fünf Punkten bewer- 
tet. Da spáter einmal zwei Spie- 
ler teilnehmen kónnen, sichern 
wir die Punktzahl gleich in ei- 
nem Array. Die Variable »Play- 
er« enthált die Spielernummer - 
-1 und kann so als Index für die- 
ses Array dienen. Die Punkte- 
zahl für den jeweiligen Spieler 
geben wir auf dem Bedie- 
nungsfeld aus. Am besten 
gleich über dem Gadget zum 
Umschalten der Teilnehmer- 
zahl. Die Ausgabe der Punkte 
muB sicher spáter noch ange- 
paBt und damit ófter verándert 
werden. Wir richten deshalb 
hierfür eine eigene Funktíon mit 
Namen SetP( ) (Listing 19) ein. 

Somit sind fast alle Punkte 
unserer Liste abgearbeitet. Es 
fehlt nur der zusátzlich einge- 
fügte Punkt e), der die Hilfs- 
funktion betrifft. Unsere Noti- 
zen erinnern uns: Der Spieler 
aktiviert die Hilfsfunktion mit 
der rechten Maustaste. Es sol- 
len dann Linien im COMPLE- 
MENT-Modus erscheinen, die 
zeigen, wie die Kugel an einem 
Hindernis abprallt. Dafür kón- 
nen wir die gleichen Berech- 
nungen wie in СһескВ( ) ver- 
wenden. Sie sehen, in diesem 
Fall enthalten die Notizen sogar 
die Lósung der Vorgabe! Wir 
kopieren die entsprechenden 
Zeilen aus CheckB() in eine 
neue Funktion namens Help( ) 
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(Listing 20). Beim Testen der 
Funktion fällt auf, daß unsere 
Überlegung, das eigene Spiel- 
feld-Window betreffend, richtig 
war. Lange Linien, die eigent- 
lich über das Spielfeld ragen 
würden, werden ab dem Spiel- 
feldrand automatisch nicht 
mehr dargestellt. Alle Punkte 
der Liste sind jetzt abgehakt, 
ein großer Bereich unseres 
Spiels ist fertiggestellt. Es wird 
Zeit die Notizen auszuwerten. 
Einige Punkte sind noch nicht 
berücksichtigt: 
a) Soundeffekte für Explosio- 
nen einbauen 
b) Wenn alle Zylinder zerstört 
sind, ist Spielende 
c) Hilfsfunktion zum Ausschal- 
ten von Hindernissen 

Sofort ergibt sich eine neue 
Liste, die das weitere Vorgehen 
vorschreibt. Die Daten für die 
Soundeffekte sind, mit Hilfe des 
Soundeffekte-Editors aus Son- 
derheft Nummer 4, in kurzer 
Zeit erstellt. Wir definieren eine 
Funktion mit Namen Play- 
Sound( ) (Listing 21), die uns al- 
le Geräusche abspielt. Für je- 
des Ereignis, an der betreffen- 
den Stelle im Quellcode durch 
Kommentare gekennzeichnet, 
rufen wir die Funktion mit den 
entsprechenden Parametern 
auf. Es ist sinnvoll, Kommenta- 
re an noch zu ergänzenden 
Stellen oder solchen, die an et- 
was erinnern sollen, besonders 
zu kennzeichnen. Etwa so: /* */. 
Sie müssen dann, um alle wich- 
tigen Stellen im Quellcode zu 
finden, nur nach dieser Zei- 


,chenfolge suchen. 


Was das Spielende betrifft, 
so müssen wir nur nach jedem 
Schuß (Funktion Schuss( ) [Li- 
sting 22]) prüfen, ob noch Zylin- 
der übrig sind. Dies geschieht 
durch den Aufruf der Get- 
CyINr( )-Funktion. Liefert sie 
den Wert -1, verzweigt das Pro- 
gramm nach GameOver( ) (Li- 
sting 23). Diese Funktion stellt 
das Ergebnis grafisch dar. Spá- 
ter soll sich der Spieler, bei ei- 
nem besonders guten Ergeb- 
nis, in die High-Score-Liste ein- 
tragen kónnen. 


Notiz: High-Score-Liste bei 
Spielende darstellen und 


eventuell ergánzen lassen. 


Nach einer Bestátigung baut 
DrawPlay() (Listing 6) das 
Spielfeld neu auf. Diese Funk- 
tion kónnten wir auch einset- 
zen, wenn der Spieler wáhrend 
des Spiels noch einmal von vor- 
ne beginnen móchte. 
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Notiz: Funktion »Neustart« 
einbauen. 


Diese Funktion und auch die 
zum Ausschalten der Hinder- 
nisse sollten über Gadgets im 
Bedienungsfeld zu erreichen 
sein und nicht über schwer ein- 
prágsame Tastenkombinatio- 
nen. Der Spieler muß dann 
nicht stándig zwischen Maus 
und Tastatur wechseln. Wievie- 
le Gadgets sind eigentlich in- 
sgesamt anzubringen? 

Laut unserer Notizen sind es 
genau sieben: Zwei Gadgets 
zum Umschalten der Spieler- 
zahl, auf denen auch die Punkt- 
zahl des jeweiligen Spielers er- 
Scheint, zwei Gadgets zum 
Ausschalten einer Reihe, zwei 
zum Ausschalten einer Spalte 
von Hindernissen und ein 
Neustart-Gadget. Hinzu kommt 
noch eines zum Verlassen des 
Spiels. Weiter kónnte man noch 
einen Trainer einbauen, der, so- 
bald er aktiv ist, eine Spielsitua- 
tion beliebig oft wiederholt. Bei 
dem Entwurf des Bedienungs- 
feldes hilft eine Skizze auf ka- 
riertem Blatt weiter. Die Breite 
und Hóhe des Windows sind 
bekannt. Zeichnen Sie die Be- 
dienungselemente an den ge- 
wünschten Positionen in ein 
Koordinatensystem ein und ge- 
ben Sie den Achsen die Einheit 
»Pixel«. Im Beispiel macht die 
ungerade Gadget-Anzahl Pro- 
bleme. Sie lassen sich einfach 
nicht optisch ansprechend po- 
sitionieren. Vielleicht sollte man 
eine Funktion streichen? Nein, 
besser noch eine einfügen. 


Notiz: Funktion 


den 


Replay 
letzten 


(wiederholt 
Schuß) einbauen. 


Nachdem die Gadgets nun 
endlich an den richtigen Posi- 
tionen montiert sind, werden 
Sie mit Borders versehen. Da- 
bei berücksichtigen wir natür- 
lich auch wieder unsere Licht- 
quelle. Links oben erhált das 
Gadget einen hellen, an den 
gegenüberliegenden Seiten ei- 
nen dunklen Rand. Es er- 
scheint aufgesetzt. Wáhlt nun 
der Spieler ein Gadget an, ver- 
tauschen wir die Ránder. Der 
rechte und der untere Rand 
scheinen erhellt. Als Bediener 
hat man dadurch den Eindruck, 
als kónne man das Gadget tat- 
sáchlich niederdrücken wie ei- 
nen Knopf. Weiter sollen die 
Gadgets Images erhalten, klei- 
ne Bilder also, die auf die Gad- 
getfunktion hindeuten. Danach 
geht es an die Realisierung der 


einzelnen Funktionen. Wie be- 
sprochen steht am Anfang das 
Aufstellen einer Liste. In diesem 
Fall ist sie sogar, in Form des 
Bedienungsfeldes, auf dem 
Bildschirm sichtbar. 

Die Funktion CheckGad- 
gets( ) (Listing 24) reagiert auf 
die Anwahl der Gadgets. Als 
Unterscheidung dient deren 
Kennummer. Auf jede der acht 
möglichen Nummern muß kor- 
rekt reagiert werden. Die Um- 
schaltung der Spieleranzahl er- 
folgt nach der Wahl eines Gad- 
gets mit der Nummer null oder 
eins. Der empfangenen Kenn- 
nummer entsprechend erhält 
die Variable »PlayerNr« die Zahl 
der Mitspieler -1. Eine andere 
Variable, sie heißt »Player«, gibt 
an, wer am Zug ist. Sie wird in 
Schuss( ) umgeschaltet. SetP( ) 
zeichnet in Abhängigkeit des 
Wertes dieser Variable einen 
Punkt über Gadget 0 oder 1. So 
erkennen die Spieler, wer gera- 
de am Schuß ist. 

Die Funktionen zum Aus- 
schalten der Hindernisse sind 
ebenfalls schnell installiert. Sie 
werden bei der Wahl der Gad- 
gets mit den Nummern zwei 
und drei aktiviert. Ist eines der 
Gadgets (oder beide) selektiert, 
schaltet CheckMouse() (Li- 
sting 11) je nach Wunsch eine 
Hindernisspalte oder -reihe 
aus. Hierzu reicht der Aufruf 
von TurnBar() mit den Dreh- 
punkten der Linien als Parame- 
ter. Ein Probelauf zeigt, daß 
man sehr leicht vergißt, die 
Hilfsfunktion wieder auszu- 
schalten. Wurden Hindernisse 
ungewollt ausgeschaltet, sind 
alle sorgsam vorgenommenen 
Einstellungen verloren. 

Abhilfe: Eine Rotfärbung des 
Hintergrunds zeigt den speziel- 
len Modus an und warnt den 
Spieler vor unüberlegten Ta- 
stendrücken. Das Gadget mit 
der Kennummer vier soll die 
Replay-Funktion aktivieren. Bei 
jedem Aufruf füllt die Funktion 
Schuss() ein Array mit den 
Ausgangsdaten des gerade er- 
folgten Versuchs. Die alte 
Spielszene kann, mit Hilfe die- 
ser Daten, bei der Wahl des 
Replay-Schalters rekonstruiert 
und der Schuß wiederholt wer- 
den. Die Trainerfunktion soll 
dem Spieler ermöglichen, jede 
Spielsituation beliebig oft zu 
wiederholen. Natürlich erhält er 
in diesem Modus keine Punkte. 
Zur Verwirklichung des Trainers 
können wir die Erfahrungen, 
welche wir bei der Entwicklung 
von Replay gemacht haben, 
verwenden. Der Spieler darf 
nach der Aktivierung des Trai- 
nerschalters an Kanone und 
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dem eines Videorecorders sehr ähnlich ist. Selbstverständlich können Sie Amiga-Grafiken 
walten und anzeigen lassen wie Zahlen und Texte ~ Briefmarkensammler zum Beispiel kän 
die digitalisierten Abbilder ihrer Schätze mit den zugehörigen Daten auf den Monitor bringen. 


Die Daten lassen sich als Formular oder Liste auf dem Bildschirm oder Drucker ausgeben. Voi 3 
also die Zeit des Chaos in падет Dia- oder anderen Sortimenten! 


Superbase 2 Amiga (deutsch) 

Wegen seiner Verkaufszahlen der Renner unter den Datenbanken, für den Haus- 

gebrauch ebenso geeignet wie für das Büro. Daten und Bilder lassen sich mit diesem 

mächtigen, relationalen Datenbanksystem fast spielerisch verwalten. Eine neue Form der 
Lagerhaltung ist somit beispielsweise möglich: Nicht mehr nur die Daten, sondern auch ein 
digitalisiertes Bild jedes Artikels erscheinen auf dem Monitor. Bis zu 16 Millionen Datensätze 

pro Datei und eine unbegrenzte Anzahl geöffneter Dateien sind erlaubt. Die Ein- oder Ausgabe erfolgt 
in Listen oder Formularen, die Sie sich am Bildschirm erstellen können. Weitere Leistungsmerkmale: 
Textverarbeitungsprogramm integriert, Serienbrieffunktion, speicherbare Masken, Etikettendruck uvm. 
Hardware-Anforderungen: Amiga 500, 1000, 2000 mit mind. 512 Kbyte RAM (empfohlen 1 Mbyte) 
Bestell-Nr. 54110 

Upgrade von Superbase 2 auf Superbase Professional, 516721), DM 199,-* (sFr 179,-"/6S 1990,-*) 
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Hindernissen beliebige Einstel- 
lungen vornehmen und den 
Schuß abgeben. Dann bauen 
wir, wie in Replay, die letzte 
Spielszene wieder auf. Die 
noch fehlenden Gadgets für 
Neustart und Programmende 
sind ebenfalls sehr schnell be- 
rücksichtigt, so daß sich auch 
die Installation unseres Bedie- 
nungsfeldes dem Ende nähert. 
Bei jeder sichtbaren Ergänzung 
des Reflex-Bildschirms tritt ein 
negativer Effekt immer deutli- 
cher hervor: Der Aufbau des 
Screens nimmt immer mehr 
Zeit in Anspruch. Man kann das 
Erscheinen der einzelnen Bild- 
schirmelemente mit bloßem 
Auge beobachten, was sehr un- 
professionell wirkt. Was tun? 
Wir kónnen doch kein Element 
weglassen! Man kónnte z.B. 
den Bildschirmaufbau mit einer 
Titelgrafik verdecken - aber es 
geht noch einfacher: Wir schal- 
ten, für die Zeit des Aufbaus, 
den Bildschirms mit OFF... DIS- 
PLAY ab. 

Damit ist wieder ein groBes 
Reflex-Kapitel erledigt. Nach 
unseren Notizen bleibt nur 
noch der Einbau einer High- 
Score-Liste übrig. Sie soll auf 
einem eigenen Window unter- 
gebracht und jederzeit einseh- 
bar sein. Ein eigenes Window 
ist schnell geóffnet, wir plazie- 
ren es hinter dem Bedienungs- 
feld. WriteScore( ) (Listing 25) 
listet darauf alle Siegernamen 
in unserer POut( )-Schrift (Li- 
sting 3). Durch eine bestimmte 
Aktivität des Spielers soll das 
Score-Window nach vorne 
klappen. Nur - durch welche? 
Hier hilft uns nur ein wenig Fan- 
tasie weiter. Wie stellt man z.B. 
fest, wie viele Bälle ein Spieler 
im Ziel »versenkt« hat? Klar, 
man schaut im Zielloch nach. 
Na also. Das ist doch eine Lö- 
sung: Ein B(K)lick in eines un- 
serer Ziele soll die Liste sicht- 
bar machen. Jetzt müssen wir 
nur noch dafür sorgen, daß sich 


ein Spieler bei einer besonders 
hohen Punktzahl in die Liste 
eintragen kann. Die Funktion 
Score( ) (Listing 26) sortiert die 
erreichte Punktzahl in die Liste 
ein. An der entsprechenden Po- 
sition erscheint ein String-Gad- 
get und erwartet die Eingabe 
des glücklichen Siegers. Eine 
richtige Bestenliste muß natür- 
lich auf Diskette verewigt wer- 
den. 

SaveScore() (Listing 27) 
übernimmt diese Aufgabe - 
und zwar so, daß die Liste nicht 
einfach mit einem Editor geän- 
dert werden kann. Beim Pro- 
grammstart soll die Liste gela- 
den werden - in InitData( ) paBt 
der Aufruf der LoadScore()- 
Funktion (Listing 28) am be- 
sten. Wir richten sie so ein, daß 
sie, falls sie eine Anderung be- 
merkt, alle Punktezahlen auf 
Null setzt. 

Es ist kaum zu glauben: Alle 
Forderungen sind erfüllt, und 
alle Notizen wurden berück- 
Sichtigt. Bei einem ausführli- 
chen Test der »099 Version« 
werden Kleinigkeiten geändert 
und noch einige Ideen verwirk- 
licht. Zum Schluß fehlt, neben 
einem Gadget für die Work- 
bench, nur noch die Anleitung 
des neuen Spiels. Dabei sollte 
man beachten, daß sie sauber 
gegliedert ist. Der Anwender 
sollte auf Anhieb finden, was er 
sucht. Verwenden Sie im Text 
keine Fachbegriffe. Formulie- 
ren Sie einfach und klar. Unter- 
stützen Sie den Text eventuell 
mit Zeichnungen oder Bild- 
schirmfotos. Sie finden die An- 
leitung zu Reflex im nebenste- 
henden Kasten. pe 
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tion Sonderhefte, z. Hd. Herrn Gólzer, Hans- 
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Anleitung zu Reflex 


1. Allgemeines 
2. Starten des Programms 
3. Der Bildschirm 


4. Der Schuß 
5. Wertung 
6. Tips 


1. Allgemeines 


Reflex ist ein neuartiges Schieß-Spiel, beidem es nicht darum geht, 
irgendwelche imaginären Gegner niederzumähen, sondern eine Ku- 
geldurch einen geschickten Schuß in einem »Loch« zu versenken, be- 


vor sie Schaden anrichtet. 


Dabei muß der Spieler die Bahn der Kugel vor dem Schuß genau ab- 
schätzen, denn er muß dafür sorgen, daß die Kugel auf ihrem Weg an 
möglichst vielen »Reflektorschildern« abprallt. Reflex kann man allei- 


ne oder zu zweit spielen. 


AMIGA-SONDERHEFT 7 


P ROJEKT 


2. Starten des Programms 


Starten Sie Reflex aus dem CLI, indem Sie den Programmnamen, 
gefolgt von < RETURN >, eingeben oder einfach per Mausklick von 
der Workbench. Nach wenigen Sekunden erscheint der Bildschirm 
von Reflex. Nach einem Mausklick auf dem Titel-Fenster kann das 
Match beginnen. 


3. Der Bildschirm 


Der Reflex-Bildschirm teilt sich in ein Spielfeld und ein Bedienungs- 
feld auf. 

8) Spielfeld 

Am oberen Spielfeldrand finden Sie die drei »Ziellöcher«. Ein 
»Blick« in ein solches Loch (Klick mit der linken Maustaste - Taste ge- 
drückt lassen!) zeigt Ihnen anhand einer Bestenliste, wie viele Kugeln 
bisher versenkt wurden. Es schlieBen sich sechs Reihen mit je sieben 
roten Zylindern an. Auf jedem Zylinder ist ein Reflektorschild montiert. 
Sie sehen ihn aus Ihrer Perspektive als grünen Strich. Er láBt sich mit 
der linken Maustaste in einem Lager bewegen, welches sich im Mittel- 
punkt des Zylinders befindet, Drücken Sie hierzu auf einem Ende des 
Schildes die linke Maustaste - gedrückt lassen - und bewegen Sie 
den Pointer um den Mittelpunkt des roten Zylinders. Sie kónnen fast 
jeden beliebigen Winkel einstellen, nur an einer Stelle (bei jedem La- 
ger verschieden) ist das Lager beschádigt. Dort kann das Schild nicht 
positioniert werden. Die Barriere láBt sich, wenn sie einmal im Weg ist, 
»hochkant« stellen. Klicken Sie hierzu etwa in die Mitte des Zylinders 
oder nutzen Sie einen der vorgesehenen Funktionsschalter (siehe un- 
ter b). Aber Vorsicht: Auch an dem senkrechten Schild, der vom Spie- 
ler nun wie ein grüner Punkt aussieht, kann die Kugel reflektieren! 

Wenn es Ihnen zu mühsam erscheint, die Zylindermitte zu treffen, 
hier ein Tip: Bewegen Sie den Pointer mit gedrückter linker Maustaste 
am grünen Schild entlang zur Mitte hin - oder nutzen Sie einen der 
hierfür vorgesehenen Funktionsschalter (siehe unter (b)). Am unteren 
Spielfeldrand ist eine Stange angebracht, auf der eine Kanone lángs 
der Stangenachse beweglich montiert ist. Positionieren Sie die Kano- 
ne mit der linken Maustaste: Taste drücken - gedrückt lassen - und Ka- 
none seitlich verschieben. 

b) Bedienungsfeld 

* |n der oberen Feldhálfte befindet sich die Spielstandsanzeige für 
beide Spieler. Die Anzeige für Spieler zwei ist direkt nach dem Start 
von Reflex noch nicht aktiv, d.h., Sie befinden sich im Ein-Spieler- 
Modus. Ein Klick mit der linken Maustaste auf das untere, farblich un- 
terlegte Anzeigefeld aktiviert den Zwei-Spieler-Modus. Ein roter Punkt 
zeigt an, welcher Spieler gerade am »Drücker« ist. Klicken Sie in die 
obere Anzeige, um in den Ein-Spieler-Modus zurückzukehren. 

Ein zweiter Klick auf das jeweilige Display setzt die bisher erreichte 
Punktzahl auf Null. Weiter unten sind im Bedienungsfeld noch sechs 
Schalter angebracht. Die beiden oberen davon helfen Ihnen, die Re- 
flektorschilder hochkant zu stellen. Ist der linke Schalter aktiviert, wird 
die senkrechte Reihe, die Sie nun mit der linken Maustaste anwählen, 
ausgerichtet. Der rechte Schalter funktioniert analog für waagerechte 
Reihen. Sind eine oder beide Schalter aktiv, fárbt sich der Hintergrund 
des Spielfeldes als Warnung rot, so daß Sie eingestellte Reflektoren 
nicht ungewollt verándern. Schalten Sie, wenn Sie die gewünschten 
Schilder eingestellt haben, den Modus aus, indem Sie die Schalter ein 
zweites Mal betátigen, oder aber, indem Sie die rechte Maustaste be- 
tátigen. Der Hintergrund nimmt dann wieder die alte Farbe an. 

Um ein Schild wieder in die horizontale Lage zu versetzen, klicken 
Sie einfach auf den betreffenden Zylinder. Ein Klick mit der linken 
Maustaste auf den Schalter mit dem Projektor wiederholt den letzten 
Schuß. Sie können ihn sich so mehrmals anschauen und, falls er gut 
gelungen war, Ihren Gegner durch unablässiges Vorzeigen an den 
Rand der Verzweiflung bringen. 

Rechts daneben wartet Ihr Trainer auf seinen Einsatz. Aktivieren Sie 
ihn, kónnen Sie eine Spielsituation beliebig oft trainieren. Nach dem 
Ausschalten des Trainers wird der alte Bildschirm wieder aufgebaut. 

Mit der Wahl des Raketensymbols starten Sie ein neues Spiel. 

Die Tür auf dem letzten Schalter führt ins CLI bzw. zur Workbench, 
je nachdem, von wo Sie Reflex gestarten haben. Falls Sie sich in die 
Bestenliste eintragen konnten, wird das Programm vor dem Pro- 
grammende, die Liste speichern. 


4. Der Schuß 


Drücken Sie im Bereich der Kanone die rechte Maustaste, so lösen 
Sie einen Schuß aus. Der erste Zylinder explodiert sofort unter der 
Wucht des Aufpralls. Manchmal gelingt es der Kugel, ein Hindernis zu 


überspringen, aber in der Regel wird die Kugel bei einer Kollision mit 
einem Reflektorschild in eine andere Bahn gelenkt. Dabei gilt: Ein- 
fallswinkel der Kugel ist gleich dem Ausfallswinkel. Haben Sie Schwie- 
rigkeiten, sich den Verlauf der Kugel vorzustellen, drücken Sie an der 
Stelle des Schildes, wo Sie die Kollision vermuten, die rechte Mausta- 
ste - gedrückt lassen - und bewegen Sie den Pointer in Richtung Ka- 
none. Jetzt erkennen Sie deutlich das oben beschriebene Gesetz der 
Winkel. Sie erkennen, wie die Kugel am Hindernis abprallt und kón- 
nen den náchsten Kollisionspunkt abschátzen. Lassen Sie sich von 
dort aus, wie beschrieben, den weiteren Bahnverlauf zeigen usw.... 
möglicherweise bis zum Ziel. Beachten Sie jedoch, daß diese MeBein- 
richtung nur korrekt funktioniert, wenn Sie den Kollisionspunkt mit der 
linken Maustaste so nah wie möglich an den grünen Schild legen. Die 
Kugel wird wáhrend des Fluges immer langsamer. Berührt sie, wegen 
der auf sie wirkenden Gravitation, den Spielfeldboden, explodiert sie 
und zerstórt dabei die drei náchstgelegenen Zylinder mit ihren Schil- 
dern. Ihr Ziel ist es also, eines der drei Löcher zu treffen, so daß die 
Kugel »unterirdisch« detoniert und keinen Schaden anrichtet. 


5. Wertung 


Wichtig für die Wertung ist die Anzahl der Kollisionen wáhrend des 
Fluges der Kugel. Diese Anzahl wird beim »Versenken« der Kugel in 
ein äußeres Loch mit fünf und, falls das mittlere Loch getroffen wurde, 
mit zehn multipliziert. 

Trifft man ein Loch, ohne daß die Kugel zuvor mit einem Schild zu- 
sammenprallte, erhält man demnach zwar keine Punkte, hat aber im- 
merhin noch den Vorteil, daß keine Zylinder zerstört werden. Spielen- 
de ist, wenn alle Zylinder zerstórt sind. 

Im Zwei-Spieler-Modus darf ein Spieler solange schieBen, wie er 
Punkte erzielt. Erst bei einer »Niete« erfolgt ein Spielerwechsel. Ein ro- 
ter Punkt in der Spielstandanzeige gibt an, wer gerade am Schuß ist. 
Haben Sie besonders viele Punkte erreicht, kónnen Sie sich mit fünf 
Buchstaben (oder Zeichen) in eine Bestenliste eintragen. Schauen 
Sie sich die bestehende Liste an, indem Sie die linke Maustaste betáti- 
gen - gedrückt lassen - wáhrend sich der Pointer über einem der drei 
»Lócher« befindet. 


6. Tips 


Reflex erscheint, zumindest am Anfang, als ein relativ schwieriges 
Spiel. Deshalb finden Sie hier ein paar Tips: 
- Móglichst bald einen breiten Durchgang nach oben schaffen 
- Versuchen Sie sich am Anfang mit nur wenigen Kollisionen. Schal- 
ten Sie die anderen Schilder aus (hochkant stellen). 
- Nutzen Sie es aus, daß der erste Zylinder zerstört wird: Befindet sich 
z. B. vor dem mittleren Loch nur noch ein Zylinder, stellen Sie das 
Schild wenn möglich waagrecht und lösen Sie einen Schuß in Rich- 
tung Loch aus. Die Kugel reflektiert am Schild, dieser explodiert, und 
die Kugel bewegt sich nach unten. Am unteren Spielfeldrand reflek- 
tiert sie wiederum und fliegt den gleichen Weg zurück und, da nun 
kein Hindernis mehr stört, geradewegs ins Zielloch. Aber mehr soll 
jetzt nicht verraten werden - versuchen Sie sich selbst!!! 


VOID OpenW() 
1/% Vorbereitungen wie Screen und Fenster öffnen usw */ 

if(!(IntuitionBases(struct IntuitionBase *) 
OpenLibrary("intuition.library",0))) CloseW(); 

if(!(GfxBase=(struct GfxBase *) 
OpenLibrary("graphies.library",0))) С1овем(); 

if(!(MathTransBase=(struct MathTransBase *) 
OpenLibrary("mathtrans.library",0)))  CloseW(); 

if(!(Screen=OpenScreen(&nser))) CloseW(); 

OFF. DISPLAY; 

ShowTitle(Sereen,0); 

ҮР =&Screen->ViewPort; 

SCRP=&Screen->RastPort; 

SetColor(); 

1f(1 (SWin=OpenWindow(&score))) CloseW(); 

SCBit=1< <SWin->UserPort->mp_SigBit; 

SRp=SWin->RPort; 

if(!(Cyly=OpenWindow(&cwin))) CloseW(); 

CBit=1< <Cyly->UserPort->mp_SigBit; 

CRp=Cyly-> RPort; 


Listing 1. OpenW() übernimmt das Öffnen 
aller Libraries und Screens fir Sie 


if(! (Bedi-OpenWindow(&bvin))) CloseW(); 
SBit=1< <Bedi->UserPort->np_SigBit; 
BRp=Bedi->RPort; 

if(! (Play=OpenWindow( &pwin) )) CloseW(); 
PBit=1< <Play->UserPort->mp_SigBit; 
PRp=Play->RPort; 

if(!(Intro=OpenWindow(&iwin))) CloseW(); 
IBit=1< < Intro- > UserPort- > mp SigBit; 
IRp=Intro->RPort; 

if(! (Process=CreateFunctionProc( “TFune”,0,TFunc, 8000) )) 
CloseW(); 

Cyly- > UserPort- mp SigTasksFindTask("TFunc"); 
if(!(Bitplane=AllocRaster(100,100))) CloseW(); 
InitTmpRas (Raster, Bitplane , RASSIZE(100,100)); 

IRp- > TmpRas=PRp- > TmpRas=BRp- > TmpRas=CRp-> TnpRass&Raster; 
InitArea(&AInfo, Buffer, 2); 

IRp- > AreaInfo=PRp- > AreaInfo=BRp-> Arealnfo=CRp- > Arealnfo= 
&AInfo; A 
SNr[0]=GetSprite(&Kanone, 3); 
SNr[1)sGetSprite(&Kugel,4); 

InitRequester(&DReq); 

DReq. Lef tEdgezDReq. TopEdgesDReq.VidtheDReq. 
Height=DReq.BackFill=2; 

SoundOn() ; 

InitData(); 


Listing 1. (Schluß) 


VOID CloseW() 
1/% zum Programmende alle Quellen schließen */ 
SHORT 1; 


1f(SData) FreeMem(SData, 1024) ; 

if(!SDev) CloseDevice(&Sound); 

if(SPort) DeletePort(SPort,sizeof(struct MsgPort)); 
for(i=0;1<2;i++)  FreeSprite(SNr[1]); 
1f(Bitplane) FreeRaster(Bitplane, 100,100); 
if(Process) CloseProcess(); 

if(Intro) CloseWindow(Intro) ; 

if(Cyly) CloseWindov(Cyly); 

1£(SWin) CloseWindow(SWin) ; 

if(Play) CloseWindow(Play) ; 

if (Bedi) CloseWindow(Bedi) ; 

if(Screen) CloseScreen(Screen) ; 
if(MatnTransBase) CloseLibrary(MathTransBase) ; 
if(GfxBase) CloseLibrary(GfxBase) ; 
if(IntuitionBase) ^ CloseLibrary(IntuitionBase); 
ON_DISPLAY; 

exit(0); 


Listing 2. CloseW() erledigt die Aufräumarbeiten bei 
Beendigung des Programms 


VOID POut(RP,col,text,xpos,ypos) 
struct RastPort XRP; 
STRPTR text; 

SHORT col,xpos,ypos; 

[/* Textausgabe Outlay */ 
Print(RP,text,3,xpos-1,ypos-1); 
Print(RP, text,4,xpos+1,ypos+1) ; 
Print(RP, text,col,xpos, ypos) ; 


VOID PIn(RP, text, xpos,ypos) 
struct RastPort *RP; 
STRPTR text; 
SHORT xpos,ypos; 

1/% Textausgabe Inlay %/ 
SetSoftStyle(RP, FSF_ITALICI FSF. BOLD, AskSof tStyle(RP)) ; 
Print(RP,text,4,xpos-1,ypos-1); 
Print(RP,text,3,xpos«1,ypos*1); 
Print(RP,text,1,xpos,ypos); 
Line(RP,3,xpos+2,ypos+10,xpos+8*strlen(text)+2,ypos+10) ; 
Line(RP,4,xpos-2,ypos*12,xpos«8*strlen(text)-2,ypos«12); 
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SetSoftStyle(RP,FS. NORMAL, AskSoftStyle(RP)) ; 


Listing 3. POut() und PIn() geben den Gadgets das 
Aussehen von realen Bedientasten 


VOID Movek(x) 
SHORT x; 

{/* Kanone nach Mauspointer bewegen */ 
REGISTER SHORT 1; 


if(x« 9) х= 9; 
if(x>233) x=233; 
if(x==LKPos) return; 
SetDrMd(PRp,JAM1); 
до! 
for(i=0;1<3;i++) Line(PRp,SCol[1],1,249+1,239,249+4) 
Block(PRp,1,x-4,248,x+3,252) ; 
MoveSprite(VP, &Kanone,x-10,235) ; 
while(((PMouseX < 9)! | (PMouseX>233)1 | (x==PMouseX) ) &&LEFTDOWN) ; 
if(PMouseY>232) x=PMouseX; 
if(x« 9) х= 9; 
1f(x2233) x=233; 
| while(LEFTDOWN) ; 
LKPos=x; 


Listing 4. MoveK() bringt das Geschütz in Stellung 


VOID DrawHole(x, f) 
SHORT x,f; 

[/* Löcher zeichen: f=-1: Flush || fe 1: Hole */ 
REGISTER SHORT 1; 


SetDrMd(PRp, JAML) ; 

for(1:0;1«4;1««)| 
SetAPen(PRp, 12«(1*f)); 
AreaEllipse(PRp,x-1,1241,10-1,9-1); 
AreaEnd(PRp) ; 


Listing 5. DrawHole() zeichnet die Ziellócher 
auf den Screen 


VOID DrawPlay(clear) 
BOOL clear; 

[/* Spielfeld neuzeichnen */ 
REGISTER SHORT i; 


if(elear) Clear(); - 

else| 
Block(PRp,1,1,24,239,230); 
MoveK(RKPos?RKPos : 122) ; 


for(1=0;1<BNr;i++) —DrawCy1(1,1); 
SetP(); 


Listing 6. Die Reflektoren setzt DrawPlay() ins Bild 


VOID InitCyl() 

|/* Ausgangsstellung Zylinder mit Barrieren */ 
REGISTER SHORT 1,j,k,nr; 
FLOAT x,y,u; 


NewRandom() ; 


for(i=0;1<Braw;i++)| 
for(j=0;j <Beol;j++){ 
nr=i*Bool+j; 
for(k=0;k<4;k++) Bar[nr].bar[k]-DBar[k]; 
Bar[nr] .BMx=18+5*34; 
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Bar[nr] .BMy=40+1#34; 

Bar[nr] .VW=99; 

Bar[nr] .Off=0; 

TurnBar(0,nr,Bar[nr] .BMx+randx(nr] ,Bar[nr] .BMyerandy[nr]) ; 

x=(FLOAT) (Bar[nr] .bar(2]-Bar{nr].ber(0]); 
FLOAT) (Bar[nr] .bar(3]-Bar(nr].bar[1]); 
ADKatan(y/(x«N05)) ; 

Bar[nr] Bii (v « 0)?180«:w; 

Bar[nr].VWsrand()/8192; /* 4 Winkel */ 


EnableReplay=0; 


Listing 7. Für lange Spielfreude sorgt InitCyl() 


VOID Макесу1() 
1/% Vorzeichen eines roten und eines gelben 
Zylinders im Hilfswindow #/ 
REGISTER SHORT 1; /* 1220 Zylinder rot || 1==1 Zylinder gelb */ 


SetRast(CRp,1); 

SetDrMd(CRp, JAM1) ; 

Гог(1=0;1<2;1++)! 
SetAPen(CRp,5*1*8) ; 
DrawCircle(CRp,1541525,15,15); 
ЅетАРеп(СЕр,6+1%8); 
AreaEllipse(CRp,17«1435,17,15,15); 
AreaEnd(CRp) ; 
SetAPen(CRp,741*8); 
AreaEllipse(CRp,1641*35,16,15,15); 

reaEnd(CRp) ; 


Listing 8. MakeCyl() arbeitet im Hintergrund, 
um einen reibungslosen Ablauf zu garantieren 


VOID DrawCyl(nr,bar) 
SHORT nr,bar; 
{/* roter Zylinder ins Spielfeld clippen %/ 
if(Bar[nr].Off) return; 
Cl1ipBlit(CRp,0,0, PRp, Bar[nr) .BMx-16,Bar[nr] .BMy-16,34,34,0xCO) ; 
if(bar) DrawBar(nr, Bar[nr].bar[0],Bar(nr].bar(1], 
Bar[nr].bar[2],Bar[nr].bar[2]); ^ 


Listing 9. Die mit MakeCyl() berechneten 
Zylinder bringt DrawCyl() ins Bild 


VOID DrawBar(nr,ax,ay,ex,ey) 
SHORT nr; 
|/* Barriere zeichnen */ 
SetDrNd(PRp, ЈАМИ COMPLEMENT) ; 
Move(PRp, ax«Bar[nr] .BMx,ay+Bar(nr] .BMy) ; 
Draw (PRp, exeBar[nr] .BMx, eyeBar(nr) .BMy) ; 


Listing 10. Das Zeichnen der Barrieren ist 
die Aufgabe von DrawBar() 


VOID CheckMouse(code) 
USHORT code; 
|/* Reaktion auf Mausklick */ 
REGISTER SHORT i,mx,my,nr,klick=0,col; 


mx=PMouseX; 
my=PMouseY; 


if (code==SELECTDOWN) { 
col=ReadPixel(PRp,mx,my); 
if((my<40)&&(co1>8)&&(co1<13)) Score(0); 


else[ 
Af(VERI. ON)| 
nreGetCylNr(mx,-1); 
for(1=0;1<Brau;i++,nr+=Bcol) 
if(!Bar[nr].Off) 
TurnBar(1,nr,Bar[nr].BMx,Bar[nr] .BMy) ; 
| 
| 
if (HORT_ON){ 
nrsGetCylNr(-1,my); 
for(i=nr;i<nr+Beol;i++) 
if(!Bar[1).0ff) 
TurnBar(1,1,Bar[1].BMx,Bar[1].BMy) ; 
| 
Af{(!VERI_ON) &&( !HORI_ON) ){ 
SetRGB4(VP,0,15,11,7); 
if(my>232) MoveK(mx) ; 
else CheckCyl(mx,my); 


| 
else if(code==MENUDOWN)| 

for(1=2;1<4;1++){ 

1f(Gad[1].Flags&SELECTED)| 
Xlickel; ' 

Gad[1].FlagssOADOHIMAGE; 
RefreshGList(&ad[1],Bedi,NULL,1); 
| - 


if(!klick)[ 
if(my>232) Schuss(); 
else Help(mx,my); 
) 
else if((!VERI_ON)&&(!HORT_ON)) ^ SetRGB4(VP,0,15,11,7); 
) 
| 


Listing 11. Die Maus im Griff mit CheckMouse() 


VOID TurnBar(draw,nr,x,y) 
SHORT draw,nr,x,y; 
[/* Winkel einer Barrier-Linie berechnen und 
Barriere darstellen */ 
REGISTER SHORT i,ntrn=0; 
SHORT ` axeBar[nr].bar[0] ,aysBar(nr].bar[1], 
ex=Bar(nr) .bar(2),ey=Bar(nr).bar(3]; 
FLOAT xp,yp,diffx,diffy,hyp,sinus=0.0,cosinus=0.0; 


diffx=(FLOAT) (x-Bar[nr].BMx) ; 
diffys(FLOAT) (Bar[nr].BMy-y) ; 
hypesqrt((diffx*diffx)«(diffy*diffy))4NOS5; 
if(hyp>30) return; 
if(hyp<5) diffxediffys0; 
if(fabs(diffx)+fabs(diffy))| 
switeh(Bar[nr].VW)| /* welcher Winkel ist verboten ? %/ 
case 0:| /* 1 */ 
ntrn=( (SHORT) (diffx> -2)&&(SHORT) (diffx<2)); 
break; 
| 
case il /*-*/ 
ntrn=( (SHORT) (diffy > -2)&&(SHORT) (d1ffy«2)); 
break; 
| 
J 
case (| /* \ #/ 
i= (SHORT) diffx+(SHORT) diffy; 
if((1>-2)8&(1<2)) ntrn=1; 
break; 


| 
i 


case 3:| /*/ */ 
1- (SHORT) dA f fx - (SHORT) di ffy; 
if((1»-2)&&(1«2)) ntrn=1; 
break; 
) 
default:break; 
} 
if(ntrn) return; /% verbotener Winkel ! */ 
sinussdiffy/hyp; 
cosinussdiffx/hyp; 
) 
for(1=0;51<4;1+=2)| 


Xpz (FLOAT)DBar|1]; 
yp=(FLOAT)DBar[i+1]; 
Bar[nr].bar[1] =(SHORT)( xpcosinus+yp*sinus) ; 
Bar[nr].bar[i+1]=(SHORT) (-xp*sinus+yp*cosinus) ; 

| 

| 

if(draw&&( (ax! «Bar[nr] .bar[0])! | (ау!=Ваг[пг].Ьраг[1])!! 
(ex! =Ваг[пг] .bar(2])1 | (ey! «Bar[nr] .bar(3])))1 
DrawBar(nr,ax,ay,ex,ey); /* löschen, dann zeichnen: %/ 
DrawBar(nr,Bar[nr].bar[0],Bar[nr].bar[1], 

Bar[nr].bar[2],Bar[nr].bar(3]); 


l 


Listing 12. TurnBar() hat den Dreh raus 


SHORT CheekH() 

1/% ist die Kugel versenkt? */ 
SHORT n,p,i,x,col,stop=0; 
FLOAT sx, sy; 


colsReadPixel(PRp, (SHORT) xpos, (SHORT) ypos) ; 
1f((c012 8)&&(co1« 13))| 
if( (xpos > =50.0)&&(xpos < =70.0)) stop=x= 60; 
else if((xpos>=110.0)&&¢xpos<=130.0)) 
else if((xpos>=170.0) &&(xpos < =190.0)) 
} . 
if(stop)| 
р=((х==120)?10:5); 
мп11е(( (5НОВТ) хро! ss) ( (SHORT) уров! =16) ){ 
вх-(хров< (FLOAT)x)?1.0:-1.0; 
ву-(уров<16.0) ?1.0:-1.0; 
if((SHORT)xpos!ex) хровж-(ху-вх%(.005%Ғаһв(ху))); 
1Ғ((5НОКТ)уров!-16) ypos+=(yv=sy*(.005+fabs(yv))); 
MoveSprite(VP, &Kugel, (SHORT)xpos-14, (SHORT) ypos-2) ; 


i 


Kugel OFF; 
if(!ReplayOn&&! TRAINER ОМ)| 
LPkte=p*Koll; 
Pkte[Player]+=LPkte; 
| 
| 
Delay(10); 
Г01(1=0;1<5;1++){ 
пагап4()/1000; /% Manx RandomNumber */ 
DrawHole(x, 1); 
PlaySound(&SData[512],10239,32) ; 
Delay(n); 
DrawHole(x,-1); 
| 
| 
return(stop); 


Listing 13. Über Erfolg oder MiBerfolg 
entscheidet CheckH() 


VOID CheckB() 

|/* Kugel-Kollision an Barriere oder Feldrand checken */ 
SHORT col,nr;kf=0; 
FLOAT h,aw,nw; 


if((col=ReadPixel(PRp, (SHORT) xpos, (SHORT) ypos) )==8){ 
if((nr=GetCy1Nr( (SHORT) xpos, (SHORT) ypos) ) > =0){ 
if(!Koll)  PutProcessMsg(FIRSTCOLLISION, nr) ; 
else if(KFlag<1) PlaySound(&SData[256],3839,16) ; 
Kolle; 
КЕ1ар++; 
хров--ху; 
уров--уу; 
if(KFlag>5)| 
KFlag=0; 
xpos+=xv<071.0:-1.0; 
ypos+=yv<0?1.0:-1.0; 
| 
au=RADkatan(yv/(xv+N05)); 
nw=2%Bar[nr].BW-(xv< .02180+aw:aw); 
hesqrt(yvkyvexv*xv) ; 
yv=(h¥sin(nw/RAD)); 
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xv=(h*cos(nw/RAD)); 
xpos+=(2#xv) ; 
ypost=(2kyv) ; 


else| /* Feldrand */ 

1f((xpos? 240)! (xpos<1)){ 
кегі; 
if(KFlag<1) PlaySound(&SData[256],1839,16); 
xve-xv; 

if((ypos 230)! (ypos« 1))| 
kfz1; 
if(KFlag<1)  PlaySound(&SData[256), 1839,16); 
yve-yvi 


KFlag=kf; 


Listing 14. Bei Kollisionen ist CheckB() gefragt 


VOID KillCyl(nr) 
SHORT nr; 
[/* Zylinder löschen %/ 
Bar[nr].Offel; 
Block(PRp, 1,Bar(nr].BMx-16,Bar(nr] .BMy-16, 
Bar[nr].BMx«16, Bar[nr] .BMy+16) ; 


Listing 15. Mit KillCyl() werden Zylinder gelöscht 


VOID InitData() 
[/* Initialisierung und Vorberechnung verschiedener Daten */ 
REGISTER SHORT 1,J,n,x,y,inc; 


srand(VBeamPos()); /% Start für Manx RandomNumber */ 
if(!(SDatasAllocMem(1024,MEMF CHIP)))  CloseW(); 
for(i=0;1<1024;1++) SData[i]=SD[1];/* Sound-Daten auf LONG */ 
for(1«START,nz0;n < KREISE; Lu INCREMENT ‚n++) 
[/* Explosion berechnen */ 
іпе-і/РОМКТЕ; . 
for(x=J=0;J < PUNKTE; x««1ne, J++)| 
у= (SHORT) sqrt( (FLOAT) (1*1«x*x)) ; 
Exp[n](J](0]» x; 
Exp(n)(JJ(1)= y; 
Exp[n] (J) [2 
Exp[n](2](3 
Exp[n][J][4]= 
Exp[n](][5 
Exp[n](3(6. 
Exp[n][J][7]= 


LoadScore(); 


Listing 16. InitDat sorgt für Tempo 
durch Vorausberechnung 


VOID TFunc() 
[/* SubProcess: zuständig für Explosion und Geräusche */ 
struct IntuiMessage *mes; 
LONG z; 
ULONG class; 
USHORT code; 
REGISTER SHORT 1,j,k,1,x,y,n; 
BOOL ende=0; 


geta4(); 
while(!ende){ 
Wait(CBit) ; 
while(class=GetMessage(Cyly, &eode,0)){ 
switch(class){ 
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case FIRSTCOLLISION:[ 
ExCy1(code); 
Delay(4); 
PlaySound(&SData[768],12979,32) ; 
Bar[eode].Off=1; 
KillCyl(code); 
for(1-0;1« KREISE; 1++)| 
for(J20;] <2;J++)[ 
if(j) Delay(4); 
for( « PUNKTE; k++)| 
Ғог(1=0;1 < КООХҮ;1+=2)[ 
SetDrMd(PRp, JAM1l COMPLEMENT) ; 
xsBar[code] .BMx«Exp[1) [k] [1]; 
ysBar[code] .BMy+Exp(1) [K] [141]; 
Move(PRp,x-1,y); 
Draw(PRp,x+1,y); 
Move(PRp,x,y-1); 
Draw(PRp,x,y+1) > 
| 


break; 

case МОРО: 1 
PlaySound(&SData[0],12031,64) ; 
break; 


n=((n+1) > 127)?0:п+1; 
PlaySound(&SData[256] ,839+Drums(n]*1000, 32) ; 
Delay(6); 
etMessage(Cyly,0,0); 
] vhile(class!sSOUND. OFF); 
break; 


case CLOSETASK:| 
ende=1; 
break; 


default: break; 


Listing 17. Nutzen Sie die Fähigkeiten 
des Multitasking mit TFunk() 


SHORT GetCylNr(mx,my) 
SHORT пх,пу; 
[/* Nummer des nächsten (bezüglich der mx/my Position) 
Zylinders ermitteln */ 
REGISTER SHORT 1; 
SHORT nr=-1,w=0,min=1000; 


for(1=0;1<BNr;1++){ 
if((my«0)H I (mx<0)II (Bar[1].0ff==0)){ 
W=ABS(Bar[1) .BMx-mx)+ABS(Bar(i] .BMy-my) ; 
if(w< ) 


return(nr) ; 


Listing 18. GetCyINr() lokalisiert die von der 
Explosion betroffenen Zylinder aus 


VOID SetP() 
[/* Punktzahlen darstellen */ 
REGISTER SHORT 1; 


229/906 


Deluxe Paint III 
Als die Dilder 
lauten lernten 


DPaint || war bisher das leistungs- 
fáhigste Malprogramm auf dem 
Amiga. Diese Zeiten sind glücklicher- 
weise vorbei, denn nun gibt es 
Deluxe Paint III! Ob Sie Zeichentrick- 
Pionier im eigenen Heimkino sind 
oder fernsehgerechte Vorspánne 

für Ihre Videofilme erzeugen wollen, 
ob Sie Grafik beruflich benótigen 


Markt&Technik 


Zeitschriften - Bücher 
Software - Schulung 


oder als Hobbymaler auf den Spuren 
der großen Meister wandeln: Mit 
Deluxe Paint III eröffnen sich Ihnen 
Möglichkeiten, die Sie bisher für 
unmöglich gehalten haben. Was das 
Programm so alles kann? 


e Alle Funktionen von Deluxe Paint II 

• Extra Halfbrite-Modus für 64 Farben 

* Beliebige Definition und Hand- 
habung von Pinseln 

* Spezielle Maleffekte wie Schattie- 
ren, Verschmieren, Weichzeichnen, 
Farbverlauf, Sprühdose 

* Neue Füllfunktionen 

* Exaktes Zeichnen geometrischer 
Formen 

e Schnelle Perspektive-Funktion für 
3-D-Grafiken 

* Alle Amiga-Zeichensätze sowie 


spezielle Color-Fonts nutzbar 

e Overscan-Unterstützung 

e Filme aus Einzelbildern erstellen 

e Pinselanimation: Jeder Teil eines 
Filmes kann als Pinsel ausgeschnit 
ten werden, und ist selbst wieder 
ein kleiner Film 

* Bewegen-Option: Jeder Pinsel kan 
in jede beliebige Richtung bewegt 
‚und dreidimensional gedreht 
werden, ja sogar bei der Bewegung 
»Spuren« hinterlassen. DPaint III 
macht daraus automatisch einen 
Film. 

• 1 Mbyte RAM reicht für kreative 
Animationen 

* ANIM-Speicherformat - Kompa- 
tibilität zu anderen Animations- 
programmen 


Hardware-Anforderungen: 
Amiga mit mindestens 1 Mbyte RAM. 


Deluxe Paint Ill deutsch 
Bestell-Nr.: 54138 

DM 249, 

(sFr 225,--*/6S 2490,--* 

Update von Deluxe Paint 11 

auf Deluxe Paint 111 

(gegen Einsendung der Original- 
diskette und Verrechnungsscheck) 
Bestell-Nr. 54138U 

DM 99,--* (sFr 89,--*/0S 990,--*) 
Für alle Amiga-Einsteiger: 

Deluxe Paint ІІ deutsch 
Bestell-Nr.: 54140 

jetzt DM 149,-* 

(sFr 135,-*/6S 1490,-*) 


*Unverbindliche Preisempfehlung 


Deluxe Paint Ill Demo 
Demo-Versionen erhalten Sie gegen 
Vorauskasse direkt beim Verlag. 
Bestell-Nr. W718 

DM 15,- 


ELECTRONIC ARTS* 


Markt&Technik-Produkte 
erhalten Sie bei Ihrem Buch- 
oder Computerfachhändler 


'INFO-COUPON 


Bitte senden Sie mir weitere Informationen 
zu Deluxe Paint III 


Name 

| 

| Straße 
PLZ/Ort 


Bitte ausschneiden und senden an: Markt&Technik Verlag AG, 
Buchverlag, Frau Brosien, Hans-Pinsel:Str. 2, 8013 Haar 


TEXT р(211101; Delay(50); 
for(1=0;1<BNr;i++) Ваг[1]=ТВаг[1]; 
DrawPlay(0); 

} 

Kugel OFF; 

1f(!LPkte&&! ReplayOn&&! TRAINER. ON)[ 
if(PlayerNr) Player=(Player==0)?1:0; 
else Player=0; 


WAKE; 
SetP(); 
if(GetCylNr((SHORT)xpos, (SHORT)ypos) <0) GameOver(); 


SetOPen(BRp,4) 

Ёог(1=#0;1<2;1++)[ 
Block(BRp,1+(1-PlayerNr)*1*13,4,73+1*15,71,88+1*15); 
sprintf(p[1], "%d”,Pkte[1]); 
POut(BRp,14,p[1],7,78+1%15) ; 

] 

SetAPen(BRp,7) ; 

AreaE11ipse(BRp,63,81+Player*15,2,2) ; 

AreaEnd(BRp) ; 

BNDRYOFF(BRp) 5 


| 
| 


Listing 22. Schuss() bringt Action ins Spiel 


Listing 19. Die Ausgabe der Punkte erfolgt über SetP() 


VOID GaneOver()* 

[/* Spielende: Auswertung */ 
SetOPen(PRp,9) ; 
Block(PRp,12,60, 50,180,100); 
Block(PRp, 2, 2,105,238,230); 
BNDRYOFF(PRp) ; 
POut(PRp,7," Game Over ",68,70); 
Score(1); 
NewScore=0; 
DrawPlay(1); 


VOID Help(mx,my) 
SHORT mx, my; 

[/* Bestimmung des Ausfallwinkels per Maus */ 
SHORT nr, fx=mx, fy=my; 
FLOAT h,aw,nw,xv,yv; 


if((nrsGetCylNr(fx,fy))«0) return; 

dof 
xv=(FLOAT) (fx-mx) ; 
yv=(FLOAT) (fy-my) ; 
aw=RAD*atan(yv/(xv+NO5)); 
nws2XBar[nr] .BW-(xv« .0?180+aw:aw) ; 
hesqrt(yvkyvexvixv) ; 
yv=(h¥sin(nw/RAD) ); 
xv=(h*cos(nw/RAD)) ; 
DrawHLine(mx,my, fx, fy, (SHORT) xv«fx, (SHORT) yv+fy) ; 
while( (mx==PMouseX) &&(my==PMouseY) &&RIGHTDOWN) ; 
DrawHLine(mx, my, ех, fy, (SHORT) ху+ех, (SHORT) yv+fy) ; 
mx=PMouseX; 
my=PMouseY; 

] wh11e(RIGHTDOWN) ; 


x 


Listing 23. Das bittere Ende: GameOver() 


BOOL CheckGadgets(id) 
SHORT 1d; 

[/* Reaktion auf Gadgetwahl %/ 
REGISTER SHORT 1; 
BOOL Quit=0; 


| 


Listing 20. Eine große Hilfe für die 
Flugbahnberechnung ist Help() 


switeh(id)[ 

case 0: /* ein Spieler */ 

case 1:] /* zwei Spieler */ 
if(PlayerNresid) Pkte[id]=0; 
else Player=PlayerNr=id; 
SetP(); 
break; 

| 

сазе 2: /* Horizontale nullen #/ 

case 3:1] /* Vertikale nullen %/ 
4f((1HORI_ON) &&(1!VERI_ON)) SetROBA(VP,0,15,11,7) ; 
else SetRGB4(VP,0,15,0,0); 
break; 


VOID PlaySound(Data, Period, Volume) 

UBYTE *Data; 
UWORD Period; 
SHORT Volume; 

[/* Geräusch (Data) abspielen */ 
if(!CheckIO(&Sound)) ^ AbortIO(&Sound); 
Sound.ioa_Data=Data; 
Sound.ioa_Period=Period; 

Sound. Lon VolumesVolume; 
BeginIO(&Sound); 


| 
| 


case 4:| /% Replay */ 
if(!EnableReplay) break; 
SLEEP; 
ReplayOn=1; 
for(1=0;1<BNr;i++) Bar[i]-RBar[1]; /* Replay-Bild */ 
DrawPlay(0); 
WAKE; 
Delay(50); 
Schuss() ; 
ReplayOn=0; 
break; 


Listing 21. Für richtige Spielhallenatmosphäre 
sorgt PlaySound() 


VOID Schuss() 
[/* ein Schuß aus der Kanone abfeuern */ 
REGISTER SHORT 1; 


| 

сазе 5:| /% Trainer */ 
if(TRAINER.ON) for(i=0;i<BNr;i++) Тваг(11-Ваг(1); 
break; 


1 
| 


сазе 6:1] /% NewGame %/ 
ReplayOn=LKPos=NewScore=0; 
for(1=2;1<6;1++) Gad[2].Flags=GADGHIMAGE; 
RefreshGList(&Gad(2] ,Bedi,NULL,4) ; 
DrawPlay(1); 
break; 


SLEEP; 

EnableReplay=1; 

RKPos=LKPos; 

for(i-0;1«BNr;le«) АВаг[1)=Ваг[1); 

LPkte=Koll=0; /* Anzahl Punkte/Kollisionen auf 0 %/ 
19; /* Geschwindigkeitsvektoren */ 


FLOAT) (Kanone.x+9);/* Startposition der Kugel X,Y */ 
ypos=230.0; 

while(MKugel()==0); /% warten solange die Kugel läuft */ 
while(GetMessage(Play,0,0)); 

if (TRAINER_ON)[{ 


case 7:] /% Ende */ 
Quite: 
break; 
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Listing 24. Treffen Sie Ihre Wahl mit CheckGadgets() 


default: break; 
| 


return(Quit); 


VOID WriteScore() 
[/* Score neuschreiben %/ 


| 


REGISTER SHORT 1; 


SetRast(SRp,2); 
Line (SRp,4,0, 25,75, 25); 
Line(SRp,3,0,233,75,233); 
POut(SRp,7, "HighScore",1,10); 
for(1=0;1<SIEGER;1++)| 
POut(SRp, 1,8Sieger[1][0], 1,32+1%10); 
POut(SRp, 15, &Punkte[1](0],43,3241*10) ; 


POut(SRp,7, "* Klick *",1,40«1*10); 


Listing 25. Die glorreichen 20 auf einen Blick 
mit WriteScore() 


VOID Score(check) 


BOOL check; 


1/% Score darstellen und eventuell Name eintragen lassen */ 


LONG bit; 

REGISTER SHORT 1,8%--1,8Пг; 
USHORT code, 1d; 

BOOL player=0; 

TEXT Kommentar[2) [21]; 


PutProcessMsg(SOUND ON, 0) ; 
ActivateWindow(SWin) ; 
if(check)| 
player=1; 
if(PlayerNr) snr=Pkte[1]>Pkte[0]?1:0; 
else snr=0; 
for(1=SIEGER-1;1>=0; 
1--) if(Pkte[snr]? satoi(Punkte[1])) st=4; 
| . 
if(st>=0)[ 
ScoreOn=NewScore=1; s 
for({=SIEGER-1;1>=st;1--)| 
strepy(&Sieger[1«1][0], &S1eger(1]([0]); 
stropy(&Punkte[1«1] (0), &Punkte[1) [0]) ; 
sprintf(&Punkte[st)(0], "$4d", Pkte(snr]) ; 
WriteScore(); 
Sieger[st][0]='\0'; 
SInfo.Buffer=&Sieger[st][0]; 
SGad. Topkdge=32+5t*10; 
RefreshGadgets(&SGad,SWin, NULL) ; 
WindowToFront(SWin) ; 
ActivateGadget(&SGad,SWin, NULL); 
if(PlayerNr) 
sprintf(Kommentar[0], "sd Punkte für Spieler fd!", 
Pkte[snr],snr+1); 
else 
sprintf(Kommentar[0],"Sie erzielten fd Punkte! ”, 
Pkte[snr]); 
sprintf(Kommentar[1],"Das bedeutet: Platz £d !”,st+1); 
PIn(PRp," Ein SUPER - Spiel !!! ",10,130); 
Ғот(1=0;1<2;1++) POut(PRp,4, Kommentar[1],15,170*1*15); 
del 
bit=Wait(PBitl SCBit) ; 
if(bit&PBit) win=Play; 
else win=SWin; 
GetMessage(win, &code, &id) ; 


id=0; 
SGad.TopEdge=-10; 
WriteScore(); 


) 


] while(code!=SELECTUP) ; 


AMIGA-SONDERHEFT 7 


P ROJEKT 


SaveScore(); 


1 
| 


е1зе| 
if(player)| 

if(PlayerNr) 
sprintf(Kommentar[O],"Xd Punkte für Spieler #d!”, 
Pkte[snr],snr«1); 
else 
sprintf(Kommentar[0],"Sie erzielten fd Punkte!", 
Pkte[snr]); 
PIn(PRp," Ein wirklich gutes Spiel ! ",10,130); 
POut(PRp,4,Kommentar[0],15,170); 
POut(PRp,4, "Trainieren Sie weiter so! ",15,185); 


SGad,TopEdge=-10; 

WindowToFront(SWin); 

do| 
bit=Wait(PBitl SCBit) ; 
if(bit&PBit) win=Play; 
else winsSWin; 

GetMessage(win, kcode,0); 

] while(code! =SELECTUP) ; 


WindowToBack(SWin) ; 
PutProcessMsg(SOUND_OFF,0) ; 
WriteScore(); 


Listing 26. Sind Sie würdig für die High-Score-Liste? 
Score() gibt Ihnen die Antwort. 


VOID SaveScore() 

[/* Bestenliste (wenn möglich) speichern */ 
REGISTER SHORT 1; 
FILE *file; 


if(NewScore&&(file=fopen(SCORE, "w”)))[ 
for(1-0;1« SIEGER; 1++){ 
furite(&Steger[1)([0],sizeof(Sieger(1]),1,f11e); 
KPkte[1]eato1(&Punkte[1](0) ; 
furite(&Punkte[1)[0],sizeof (Punkte[1]) 1, file); 
furite(&KPkte[1],sizeof (SHORT) 1, file); 


felose(file); 


ScoreOn=NewScore=0; 


| 
| 


Listing 27. SaveScore() verewigt Ihre Taten auf Diskette 


VOID LoadScore() 

[/* Bestenliste laden */ 
REGISTER SHORT 1; 
FILE *file; 


1f(filesfopen(SCORE, "r"))| 
for(120;1« SIEGER; t)| 
fread(&Sieger[1](0],sizeof(Steger[1]) ,1,?11e); 
fread(&Punkte[1)[0) ,sizeof (Punkte[1]) ,1,f11e) ; 
fread(&KPkte[1],sizeof(SHORT),1,f11e); 
1f(KPkte[1]! =atoi (&Punkte[1] [0]))| 
strepy(&Punkte[1][0]," 0”); 
NewScore=1; 


| 
| 


Sieger[1][5]=Punkte[1][4]= 


| 


felose(file); 


else for(1=0;1<SIEGER;i++)| 
strepy(&Steger[1][0], "= Pë 
Strepy(&Punkte[1][0]," 0%; 


Listing 28. Erinnerung aus vergangenen 
Tagen mit LoadScore() 


Bibliothek für Echtzeit-Vektorgrafik Rasante Flüge 
durch das All. 
Raumschiffe in 

Richtung Zukunft. 

für Zeit und Raum. 
Das Erleben neuer 
Dimensionen. 
Keine Utopie, 
sondern Realität: 
Vektorgrafik 
macht’s möglich. 
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Ein neues Gefühl 
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Von Heiko Schlichting, 
Dirk Mehren und Martin Jobst 


iele tolle Spiele für 
den Amiga faszi- 
nieren mit animier- 
ter — Vektorgrafik: 
Elite, Starglider 
oder Starwars. Si- 
cher hatten Sie 
auch schon einmal 
den Wunsch, Ihre Programme 
mit solcher Grafik auszustatten. 
Wenn Sie bis jetzt nicht wußten 
wie, bieten wir Ihnen eine opti- 
male Lósung: die C-Bibliothek 
»VG«. Mit Hilfe der eingebau- 
ten, schnellen Grafikroutinen 
kónnen Sie Ihre C-Programme 
mit schneller Vektorgrafik ver- 
sehen. Die Anwendung ist 
denkbar einfach. 

Für viele Zwecke reicht die 
zweidimensionale Darstellung 
der Amiga-Systembibliotheken 
nicht aus, gerade Spiele gewin- 
nen durch dreidimensionale 
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Grafik an Reiz. Die effektive 
Darstellung ráumlicher Objekte 
ist die Domäne der Vektorgra- 
fik. Sie erlaubt die schnelle Be- 
rechnung sowie die räumliche 
Darstellung und Bewegung al- 
ler Körper, die sich aus Linien 
aufbauen lassen. 

Ist beispielsweise beim Ray- 
tracing-Verfahren das Ziel die 
realitätsnahe Darstellung, bie- 
tet Vektorgrafik die Möglichkeit, 
schnell einfache Objekte zu 
konstruieren. Da Vektorgrafik 
nur einen Bruchteil der Re- 
chenleistung eines Raytracing- 
Bildes benötigt, kann eine Be- 
wegung auch in Echtzeit be- 
rechnet und dargestellt werden. 
Was bedeutet, daß die einzel- 
nen Bilder der Animation nicht 
im voraus, sondern Bild für Bild 
während des Ablaufs »live«, al- 
so in Echtzeit berechnet wird. 
Dazu sind jedoch sehr aufwen- 
dige mathematische Berech- 
nungen nötig. Mit Hilfe der Ma- 
trizenrechnung können diese 


aber übersichtlich und schnell 
durchgeführt werden. 

Vektorgrafik oder »VG« arbei- 
tet objektorientiert, wobei ein 
Objekt aus einzelnen Punkten 
besteht, die Sie ráumlich relativ 
zueinander setzen, verbinden 
und freiim Raum bewegen kón- 
nen. »VG« ist die Weiterenwick- 
lung eines Moduls, das Struktu- 
ren von Molekülen darstellen 
kann. 

Um Ihnen den Gebrauch von 
Vektorgrafik móglichst einfach 
zu machen, sind alle nótigen 
Funktionen so geschrieben. 
daB Sie Objekte leicht kreieren 
und in eigenen Programmen 
benutzen kónnen. Ein Beispiel- 
programm finden Sie in Listing 
3. 


»VG« erledigt alle komplizier- 
ten mathematischen Berech- 
nungen mit wenigen Befehlen, 
deshalb ist es nicht nötig. daß 
Sie die mathematischen Grund- 
lagen allzu genau kennen. Um 


uns auf wesentlichere Dinge zu > 
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beschränken, verweisen wir für 
weitergehende Informationen 
auf ein beliebiges Mathematik- 
buch, das sich mit linearer Al- 
gebra befaßt. Nachfolgend fin- 
den Sie eine Beschreibung al- 
ler Funktionen von »VG«, die 
Sie außerdem in Tabelle 1 als 
Übersicht finden. Den Source- 
Code von »VG« sehen Sie in Li- 
sting 1, das zugehörige Include- 
File »VG.h« zeigt Listing 2. Ne- 
benstehende Kästen zeigen Ih- 
nen, was Sie beim Compilieren 
und Linken des Programms be- 
achten sollten. 


VGopen: 

Diese Funktion muß immer 
als erste aufgerufen werden, da 
sie die nötigen Amiga-Biblio- 
theken (»Intuition«, »Graphics«, 
»Mathffp« und »Mathtrans«) be- 
reitstellt. Außerdem reserviert 
sie den benötigten Speicher 
und öffnet einen Screen in der 
gewünschten Auflösung. Die 
Farben werden auf voreinge- 
stellte Standardwerte gesetzt, 
Sie können sie aber nachträg- 
lich Ihren Bedürfnissen anpas- 
sen. 

Mit den Parametern »Auf- 
IsgX«, »AuflsgY« und »Bitpla- 
nes« bestimmen Sie den Typ 
des Screens. Mögliche Werte 
für die horizontale Auflösung 
sind 320 oder 640, für die verti- 
kale 200, 256, 400 oder 512. Der 
Screen kann bis zu fünf Bitpla- 
nes erhalten. Bedenken Sie 
aber, daß jede zusätzliche Bit- 
plane neben der Farbenpracht 
aüch Rechenzeit kostet. Die 
Anzahl der für die Linien zur 
Verfügung stehenden Farben 
können Sie mit der Formel »Far- 
ben=2°Bitplanes-1« berechnen. 

Damit Sie sich nicht um die 
interne Verarbeitung der Koor- 
dinaten kümmern müssen, be- 
nötigt das Programm die maxi- 
male Anzahl der später verfüg- 
baren Punkte und Linien. Diese 
Werte werden in »MaxLines« 
und »MaxPoints« an die Funk- 
tion übergeben. Sie sollten die- 
se Werte ruhig etwas größer di- 
mensionieren, um einen Puffer 
zu haben. Die einzige Begren- 
zung ist der zur Verfügung ste- 
hende Speicherplatz. 

Mit dem letzten Parameter 
von »VGopen« hat es eine be- 
sondere Bewandtnis. Da »VG- 
open« einen eigenen Screen öff- 
net und Sie deshalb Fehlermel- 
dungen nicht sehen kónnen, 
gibt es die Móglichkeit, diese in 
ein Textfile schreiben zu lassen. 
Es genügt, wenn Sie dem Para- 
meter »ErrFile« einen Filena- 
men samt Pfad übergeben. 

In unserem Beispiel haben 
wir die Ausgabe in das File 
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»RAM:SYSPRINT« gesendet. 
Spáter folgende Fehlermeldun- 
gen werden dem bestehenden 
File hinzugefügt. Damit Sie die 
Übersicht bewahren, werden 
den Fehlern auch Datum und 
Uhrzeit sowie die Funktion, die 
den Fehler signalisierte, mitpro- 
tokolliert. Auf diese Weise kón- 
nen Fehler spáter beser nach- 
vollzogen werden. Wenn Sie 
»ErrFile« auf Null setzen, kón- 
nen Sie die Fehlerausgabe un- 
terbinden. Eine Ausgabe nach 
»stderr« (normalerweise das 
aufrufende CLI) erfolgt in jedem 
Fall. Eine genaue Beschrei- 
bung aller móglichen Fehler- 
meldungen samt ihren Ursa- 
chen finden Sie in Tabelle 2. 


Screen gesetzt. Diese kónnen 
mit »VGcolor« geändert wer- 
den. Die ersten beiden Parame- 
ter bestimmen Anzahl und Posi- 
tion der Farbe(n) in der Palette. 
Verándern Sie Farben, die bei 
den gewáhlten Bitplanes nicht 
genutzt werden, so zeigen sich 
keine Auswirkungen auf die 
Darstellung. Der letzte Parame- 
ter ist ein Zeiger auf eine Farb- 
tabelle vom Typ »VGColor« (sie- 
he Tabelle 3, dort werden die 
vom Include-File »VG.h« vorde- 
finierten Strukturen erklärt). 


VGpoint: 

Diese Funktion -definiert ei- 
nen Punkt in der Darstellung. 
Übergeben Sie ihr die Objekt- 


Linker-Optionen 


Das File »VG.O« sowie ein entsprechendes weiteres Programm wie 
«VGTest.o« werden zusammen mit der »m32.lib« und der »c32.lib« ge- 
linkt. Die »m32.lib« ist die Mathematik-Library für 32 Bit Integer. Die 
»c32.lib« enthält die Aufrufe für die Amiga- und Aztec-Funktionen. 
Wichtig ist beim Aufruf die Einhaltung der Reihenfolge: zuerst die 
».O«-Files, dann die »m32.lib« und die »c32.lib«. 

Die verwendeten Optionen sind »-o file« und »-Lname«. Die »-o file«- 
Option erlaubt Ihnen, den Namen des ausführbaren Files anzugeben. 
»-Lname« durchsucht die angegebene Library nach benótigten Modu- 


len. 
Anweisungen: 


In VG.O VGTESTO -Lm32 -Lc32 -o VGTEST 


Compiler-Optionen 


Die Files kónnen mit dem Aztec C68K 3.6a compiliert werden. Ver- 
wenden Sie dabei folgende Compileroptionen: 


-е140 +1 


»-e140« vergróBert den »Expression-Space«. Diese Option wird bei- 
spielsweise für mathematische Ausdrücke benötigt. Man erweitert da- 
mitdie mógliche Lánge von Ausdrücken, die der Compiler verarbeiten 


kann. 


»-l«: interne Variablen sind nicht mehr 16, sondern 32 Bit groß 


Anweisungen: 
сс -e140 «1 VG.C 
cc +1 VGTEST.C 


VGclose: 

Diese Funktion beendet die 
Vektorgrafikdarstellung. Der re- 
servierte Speicher wird wieder 
freigegeben, der Screen und 
die Bibliotheken geschlossen. 
Mit dem Parameter »end« kón- 
nen Sie bestimmen, ob Sie Ihr 
Programm mit dieser Funktion 
verlassen möchten (FALSE= 
Programm beenden). Da die in 
den meisten Fällen nicht ge- 
wünscht wird, sollten Sie diese 
Funktion mit VGclose(TRUE); 
aufrufen, woraufhin nur die 
Vektorgrafikfunktion beendet 
wird. 


VGcolor: 

Beim Aufruf von »VGopen« 
werden bereits voreingestellte 
Farbwerte für den neuen 


nummer (1-32767) und ein Feld 
mit den drei Koordinaten. Die- 
ses Feld sollte vom Typ »union 
VGzahl MeineKoordinaten[VG- 
DIM]« sein. Sie kónnen die X- 
Koordinate dann mit »Meine- 
Koordinaten[0].f=(float)0.0234« 
zuweisen. 


Farbenpracht 


Die Y- und Z-Koordinate kön- 
nen Sie entsprechend zuwei- 
sen, setzen Sie nur entspre- 
chend [1] bzw. [2] ein. Dabei ist 
wichtig, daß Sie Variablen vom 
Typ »union VGzahl« als float- 
Variable ansprechen. Sie müs- 
sen den Suffix ».f« bei den Va- 
riablen angeben. Der Wertebe- 
reich der Koordinaten reicht un- 
abhängig von der Auflösung 


immer von -1.0 bis +1.0. Dies 
gilt für die horizontale wie für 
die vertikale Achse. Der Ur- 
sprung eines von »VG« definier- 


Funktionen 


Return-Wert Funktion 


void VGopen 
(AuflsgX, 
AuflsgY, 
BitPlanes, int 
MaxLines, 
MaxPoints, 
ErrFile) 


VGclose 
(end) 


VGcolor 
(Pos, 
Anzahl, 
Colors) 


VGpoint 


VGline 
(Num, 
Anfang, 
Ende, 
Color) 


VGeraseobj 
(PointObj) 


VGeraseline 
(LineNum) 


VGreaddata 
(FileName) 


VGrotate 
(RMatrix, 
Xangle, 
Yangle, 
Zangle, 
clear) 


VGtranslate 
(RMatrix, 
Et, 

E2, 

E3, 

length, 
clear) 


VGglobalscale 
(RMatrix, 
scalefactor, 
clear) 


VGlocalscale 
(RMatrix, 

Е; 
scalefactor, 
clear) 


VGtransform 
(Obj, 
Matrix) 


VGdisplay 
(clear) 


Tabelle 1. Alle von »VG« zur Ver- 
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ten Koordinatenkreuzes liegt in 
der Mitte des Bildschirms. 

Die Objektnummer eines 
Punktes kann von Ihnen frei ge- 


und Parameter 


unsigned int 
unsigned int 
char 


BOOL 


unsigned int 
unsigned int 
struct 


union (siehe Text) 
int 
int 
itn 
BOOL 


union (siehe Text) 
float 
float 
float 
float 
BOOL 


union (siehe Text) 
float 
BOOL 


union (siehe Text) 
foat 
float 
BOOL 


int 
union 


fügung gestellten Funktionen 
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wáhlt werden. Sie ermóglicht, 
daB Sie spáter Teilobjekte be- 
wegen, drehen oder vergróBern 
kónnen. Dies erreichen Sie, in- 
dem Sie mehreren Punkten die 
gleiche Objektnummer zuwei- 
sen und diese dann gemein- 
sam - als einen Kórper anspre- 
chen. Die Objektnummer 0 ist 
reserviert und bezeichnet die 
gesamten Punkte. Geben Sie 
daher nie einem Punkt oder ei- 
ner Linie die Objektnummer 0. 


VGline: 

Zwei mit »VGPoint« definierte 
Punkte kónnen durch eine Linie 
miteinander verbunden wer- 
den. Sie übergeben der Funk- 
tion »VGline« dazu eine Objekt- 
nummer, das heißt die Linie 
wird zu einem eigenen Objekt, 
oder Teil eines solchen. Dies er- 
weist sich für Bewegungsvor- 
gänge als günstig. 

Start- und Endpunkt kónnen 
Sie nicht mittels der Objekt- 
nummer angeben, vielmehr er- 
geben sich deren Nummern 
aus der Reihenfolge, wie Sie 
die Punkte mit »VGpoint« defi- 
nieren. Der erste Punkt, den Sie 
bestimmen, erhált die Nummer 
0, der zweite die Nummer 1 
usw. Verwechseln Sie diese Nu- 
merierung nicht mit den Objekt- 
nummern, die Sie bei den an- 
deren Funktionen angeben 
müssen. 

VGeraseobj: 

Mit »VGeraseobj« kónnen Sie 
ein bestimmtes Objekt lóschen. 
Sie übergeben die Objektnum- 
mer und alle mit dieser Num- 


.mer bezeichneten Punkte und 


Linien werden gelóscht. 
VGeraseline: 

Diese Funktion lóscht aus- 
schlieBlich Linien eines Ob- 
jekts. Sie brauchen dazu nur 
die Objektnummer der Linie(n) 
anzugeben. 

VGreaddata: 

Wollen Sie in einem Pro- 
gramm kein festes Objekt defi- 
nieren, sondern die Daten aus 
einem File einlesen, haben Sie 
mit dieser Funktion die Móg- 
lichkeit dazu.Das Datenfile muB 
dazu in einem ganz bestimm- 
ten Format vorliegen: 

Anzahl der Punkte 

Anzahl der Linien 
Objektnummer des Punktes 
X-, Y-, Z-Koordinate 
Objektnummer des Punktes 
X-, Y-, Z-Koordinate 


Anfangspunkt/Endpunkt/ 
Farbe der Linie 
Anfangspunkt/Endpunkt/ 
Farbe der Linie 
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Das File kann mit einem be- 
liebigen Texteditor erstellt wer- 
den. Der einzige Parameter, der 
an die Funktion »VGreaddata« 
übergeben wird, ist der vollstán- 
dige Name Ihres Datenfiles. Ein 
Beispiel finden Sie in Tabelle 4. 

Sie haben auBerdem die 
Möglichkeit, mit den Funktio- 
nen »VGpoint« und »VGLine« 
ein eigenes Modul zum Einle- 
sen von Objektdaten zu erstel- 
len. 


VGrotate: 

Nun kommt Bewegung ins 
Spiel. Mit »VGrotate« haben Sie 
die Móglichkeit, eine zuvor de- 
klarierte Matrix mit der Abbil- 
dungsmatrix für Rotationen um 
die X-, Y- und Z-Achse zu initia- 
lisieren. 

Bevor die einzelnen Parame- 
ter erláutert werden, sei darauf 
hingewiesen, daß für diese Ab- 
bildungsmatrix ein Feld in der 
Form 


union VGzahl MeineMatrix 
[VGDIM] [VGDIM] 


reserviert werden muß. Ein Zei- 
ger auf diese Matrix stellt dann 
auch den ersten Parameter der 
Funktion »VGrotate« dar. Wei- 
terhin können Sie die verschie- 
denen Drehwinkel um die drei 
Achsen des Koordinatensy- 
stems angeben. Die Werte von 
»Xangle«, »Yangle« und »Zan- 
gle« werden im Gradmaß erwar- 
tet und müssen Integerwerte im 
Bereich von -359 bis 359 sein. 
Es ist möglich, jedoch nicht not- 


wendig, ein Objekt um alle drei 
Achsen rotieren zu lassen. 
Wenn nur eine Matrix erstellt 
werden soll, die beispielsweise 
das Objekt um die X-Achse 
dreht, setzen Sie »Yangle« und 
»Zangle« auf 0 Grad. 


Drehmomente 


Der letzte Parameter der 
Funktion ist vom Type Bool und 
für die besondere Móglichkeit 
der Kombination einzelner Be- 
wegungsmatrizen vorgesehen. 
Wird an dieser Stelle »TRUE« 
angegeben, so beachtet »VGro- 
tate« die alten Werte Ihrer Ma- 
trix nicht und überschreibt sie 
einfach. Im Falle eines »FALSE« 
wird jedoch die erzeugte Rota- 
tionsmatrix der vorhandenen 
angehángt. Dies hat zur Folge, 
daB bei Ausführung beide Ab- 
bildungen (Bewegungen) si- 
multan durchgeführt werden. 
Wie viele Abbildungsmatrizen 
Sie deklarieren, initialisieren 
und verwalten, liegt in Ihrem ei- 
genen Ermessen. 

Dazu ein Beispiel: 
VGrotate(MeineMatrix, 
0,2,-15,TRUE) 

Damit speichern Sie die reine 
Rotationsmatrix mit den Werten 
für eine gleichzeitige Drehung 
um die Y-Achse mit 2 Grad und 
um die Z-Achse um -15 Grad 
(345 Grad) in »MeineMatrix«. 


Fehlermeldungen 


»OpenLibrary (Intuition) ERROR.« 


Die Intuitionlibrary konnte nicht geóffnet werden, ein gravierender 
Fehler, der normalerweise nicht vorkommen sollte. Bei seinem Auftre- 
ten ist ein Systemabsturz nicht zu vermeiden. 


»OpenLibrary (Gfx) ERROR.« 


Die Grafik-Library wurde nicht gefunden. Auch dieser Fehler tritt im 
Normalfall nicht auf, da diese Library Bestandteil des ROMs ist und 


deshalb immer verfügbar ist. 


»OpenLibrary (MathFFP) ERROR.« 


4 


Die Mathematik-Library konnte nicht gefunden werden. Auch diese 
Bibliothek ist Teil des ROMs und sollte immer vorhanden sein. Prüfen 
Sie bei Auftreten dieses Fehlers, ob die Version Ihres Kickstart kleiner 
als 1.2 ist, oder sie eine unerlaubt modifizierte Kickstart-Version be- 


nutzen. 


»OpenLibrary (MathTrans) ERROR.« 

Die Mathematik-Library für transzendente Funktionen konnte nicht 
gefunden oder geöffnet werden. Dies ist der Fall, wenn sich die »math- 
trans.library« nicht im »LIBS:«-Ordner befindet. In diesem Fall sollten 
Sie die Library von der Workbenchdiskette in Ihren aktuellen »LIBS«:- 


Ordner kopieren. 


»OpenScreen ERROR.« 

Der für die Grafik nötige Screen konnte nicht geöffnet werden. Ent- 
weder reichte das nötige Chip-Memory nicht aus, oder Sie versuchten 
auf einem NTSC-Amiga einen Screen mit PAL-Auflösung zu öffnen. 


Tabelle 2. Alle Fehlermeldungen von »VG« 
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»Out of Memory ERROR.« 

Der Speicherplatz reicht nicht aus. Verkleinern Sie in diesem Fall 
die Werte von »MaxLines« und »MaxPoints« der Funktion »VGopen« 
oder wählen Sie eine niedrigere Auflösung mit weniger Farben. 

- 


»Invalid Viewresolution (X) ERROR.« 

Der Wert für die horizontale Auflösung bei »VGopen« war nicht zu- 
lässig. Benutzen Sie nur die Werte 320 oder 640. Es wird in diesem 
Fall die voreingestellte Auflösung von 320 Pixeln automatisch ange- 
wählt. x 


»Invalid Viewresolution (Y) ERROR.« 

Der Wert für die vertikale Auflösung, den Sie als Parameter der 
Funktion »VGopen« angegeben haben, war nicht erlaubt. Verwenden 
Sie nur die Werte 200, 256, 400 oder 512. (Default: 200) 


»Bitplane ERROR.« 

Der Wert für die Anzahl der verwendeten Bitplanes darf nur im Be- 
reich von 1 bis 5 liegen (1-31 Farben + Hintergrundfarbe). Bei einem 
Fehler werden zunächst zwei Bitplanes benutzt. 


»Nothing to do: LOGIC ERROR.« 

Sie haben angegeben, daß Sie keinen einzigen Punkt und keine Li- 
nie definieren wollen. Was wollen Sie dann mit diesem Programm? 
Abhilfe: Verwenden Sie sinnvolle Werte bei »MaxLines« und »Max- 
Points«. 


»Requires Убореп ERROR.« 

Alle Funktionen erwarten, daß Sie zunächst die Funktion »VGopen« 
aufrufen. Das haben Sie in diesem Fall wohl vergessen und sollten 
dies nachholen. Rufen Sie »VGclose« auf, so sollte die náchste Funk- 
tion, die Sie aufrufen, ebenfalls »VGopen« sein. 


»Out of RGB bounds ERROR.« 

Die Farben dürfen nur mit Werten von 0 bis 15 definiert werden. Ver- 
wenden Sie Werte, die nicht in diesem Bereich liegen, so werden die 
Werte als »€MODULO 16« interpretiert. 


»Out of Colortable ERROR.« 

Die von Ihnen definierte Farbpalette kann maximal 32 Farben auf- 
nehmen. Dies ist unabhángig von der Anzahl der tatsáchlich benutz- 
ten Bitplanes. Sie versuchten aber mehr als 32 Farben zu definieren. 
SEH Sie bitte auch, daß die Farben von 0 Біз 31 numeriert wer- 

en. 


»Second VGopen without VGclose ERROR.« 

Bevor Sie »VGopen« ein zweites Mal in einem Programm aufrufen 
kónnen, müssen Sie mit der Funktion »VGclose« den Speicher freige- 
ben und den alten Screen schlieBen. Abhilfe: fügen Sie entweder ein 
»VGclose« ein oder überprüfen Sie, ob nicht »VGopen« unabsichtlich 
mehrfach hintereinander aufgerufen wurde. 


»Number of Lines > MaxLines ERROR.« 

Sie versuchten mehr Linien zu definieren, als Sie in »/Gopen« als 
Maximum angegeben haben. VergróBern Sie den Wert von »MaxLi- 
nes«, wenn Sie genug Speicherplatz haben. 


»Number of Points > MaxPoints ERROR.« 

Sie versuchten mehr Punkte zu definieren, als Sie in »VGopen« als 
Maximum angegeben haben. VergróBern Sie den Wert von »Max- 
Points«. 


»Line with undefined Point ERROR.« 

Linien können nur zwischen existierenden Punkten gezogen wer- 
den. Sie sprachen aber eine Punktnummer an, die Sie nicht definiert 
haben. 


»File not found, can't open it ERROR.« 
„ Die Funktion »VGreaddata« kann das angegebene File nicht öffnen. 
Überprüfen Sie Pfad- oder Filenamen. 


VGtranslate: 

Um ein Objekt zu verschie- 
ben, wird die Funktion »VGtrans- 
late« benótigt. Sie erzeugt die 

Parallelverschiebungsmatrix, 
die bei Anwendung alle ange- 
wáhlten Punkte um einen von 
Ihnen angegebenen Vektor ver- 
schiebt. Der erste Parameter ist 
wie zuvor bei »VGrotate« der 
Zeiger auf eine Matrix. Die 
náchsten drei Werte, die über- 
geben werden, stellen die drei 
Komponenten des  Vektors 
(XY, Z) dar und sollten - müssen 
aber nicht - im Wertebereich 
[-1.0, +1.0] sein. 

Als weiterer Parameter folgt 
die Verschiebungslánge vom 
Typ»FLOAT;«. Durch den Wech- 
sel des Vorzeichens kann die 


Richtung der Verschiebung 
umgekehrt werden. Der letzte 
Wert, der an »VGtranslate« 
übergeben wird, entspricht in 
seiner Funktion dem letzten Pa- 
rameter von »VGrotate«. 

Bei unserem Beispiel 
VGtranslate(MeineMatrix, 
0.5,-0.2,0.0,-0.1,FALSE) 
wird eine Verschiebungsmatrix 
erzeugt, die um -0.05 in X-Rich- 
tung und 0.02 in Y-Richtung 


Einer für alle 


verschiebt. Diese Matrix wird 
auf die schon bestehende Rota- 
tionsmatrix (siehe oben) in 
»MeineMatrix« aufmultipliziert. 
Auf diese Weise kónnen Sie ei- 


»Out of Line/Point-Memory ERROR.« 

Sie versuchen mehr Punkte oder Linien als zulássig einzulesen. 
VergróBern Sie die Werte von »MaxLines« und »MaxPoints« oder prü- 
fen Sie, ob es sich bei dem File um ein zulássiges Datenfile handelt. 


Tabelle 2. (Fortsetzung) 
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on »VG.h« 


Strukturen 


union VGzahl [ 
float f; 
int 1; 
}; 

»Union VGzahl« enthält eine von »VG« benutze Koordinate. Sie be- 
nötigen diesen Typ für die Definition eine Bewegungsmatrix. Eine Ma- 
trix können Sie folgendermaßen definieren: 
union VGzahl MeineMatrix(VGDIM][VGDIM]; 

Dadurch haben Sie eine Matrix mit dem Namen »MeineMatrix« defi- 
niert, die alle von »VG« erzeugten Bewegungen ausführen kann. (Der 
Wert von »VGDIM« ist 4.) 


struct VGLine [ 
` Number; 
StartPoint; 
EndPoint; 
Color; 


Diese Struktur definiert eine Linie in »VG«. Dieser Typ wird vorwie- 
gend intern benötigt, Sie können diese aber auch verwenden, um auf 
einfache Weise Linien zu definieren. Die Strukturelemente enthalten 
die Objekt-, Startpunkt- und Endpunktnummer sowie die Farbe. Be- 
achten Sie, daB die Funktion »VGline« die Strukturelemente einzeln 
benótigt und Sie diese Struktur nicht direkt übergeben kónnen. Eine 
Anwendung sehen Sie in unserem Beispielprogramm (Listing 3). 


Struet VGPoint [ 

int Object; 

union VGzahl Koord[VGDIM]; 

Ji 

Entspricht weitestgehend der Struktur >VGLine<, Die Strukturele- 

mente sind in diesem Fall aber Objektnummer und Koordinaten des 
Punktes. Beachten Sie, daß der Wert von »VGDIM« 4 ist, Sie aber nur 
Punkte im dreidimensionalen Raum definieren kónnen. Die vierte 
Koordinate wird von »VG« für interne Berechnungen verwendet, bei 
der Definition eines Punktes wird der angegebene Wert ignoriert und 
immer 1.0 dafür eingesetzt. 


struct VGColor [ 
unsigned short R,G,B; 
]; 

Diese Struktur definiert eine Farbe der Farbpalette. Die Strukturele- 
mente sind die Farbanteile in Rot, Grün und Blau. Der zulássige Be- 
reich für diese Werte sind 0 bis 15. Mit dieser Struktur wird eine Farb- 
palette an die Funktion »VGcolor« übergeben. 


Tabelle 3. Die in »VG.h« (Listing 2) vordefinierten Strukturen 
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ne kombinierte Dreh- und Ver- 
schiebebewegung erzeugen. 


VGglobalscale: 

Auch diese Funktion erzeugt 
eine spezielle Abbildungsma- 
trix, jedoch eine für die allseiti- 
ge Dehnung. Mit ihr lassen sich 
einzelne oder alle Objekte ver- 
größern bzw. verkleinern. Diese 
Funktion benötigt folgende Pa- 
rameter: »RMatrix« ist wieder 
der Zeiger auf eine Ihrer Matri- 
zen. »scalefactor« - vom Typ 
»FLOAT« - ist der Dehnungsfak- 
tor, mit dem Sie bestimmen, ob 
vergrößert (Werte größer als 1.0) 
oder verkleinert (Werte kleiner 
als 1.0) werden soll. Die Bedeu- 
tung von »clear« entspricht der 
bei »VGrotate« und »VGtrans- 
late«. 


VGlocalscale: 

Alle Parameter dieser Funk- 
tion entsprechen denen von 
»VGglobalscale«. Zusätzlich 
muß jedoch noch ein Zeiger auf 
einen Richtungsvektor (mit drei 
Komponenten X,Y,Z) vom Туре 
»FLOAT« übergeben werden. 
Der Unterschied zu der Funk- 
tion »VGglobalscale« liegt dar- 
in, daß durch den Vektor eine 
gerichtete Dehnung erzeugt 
wird. Stellen Sie sich dazu Ihr 
Objekt aus elastischem Mate- 
rial bestehend vor, das an zwei 
gegenüberliegenden Seiten 
festgehalten und auseinander- 
gezogen wird. Dazu ein Bei- 
spiel: 

Beispiel: : 
float MeinVektor[3]; 


VGlocalscale 
(MeineMatrix,MeinVektor, 
0.055, TRUE) 


VGtransform: 

Damit können Sie alle zuvor 
erzeugten Abbildungsmatrizen 
auf Ihre Objekte anwenden. Als 
erster Parameter müssen Sie 
die Objektnummer, die vom Typ 
»Integer« sein muß, übergeben. 
Wollen Sie alle Objekte gleich- 
zeitig ansprechen, muß dieser 
Parameter gleich Null sein. Als 
zweites wird ein Zeiger auf die 
anzuwendende Matrix überge- 
ben. Die Funktion »VGtrans- 
form« verändert die Punktkoor- 
dinaten der einzelnen Objekte, 
nicht jedoch die übergebene 
Matrix. 

Durch mehrfachen Aufruf mit 
derselben Matrix kann so eine 
Bewegung erzeugt werden. Zu 
beachten ist, daß diese Funk- 
tion die Objekte nicht sofort dar- 
stellt, was den Vorteil hat, daß 
Sie ein Objekt an eine bestimm- 
te Position bewegen können, 
ohne es zu zeigen. 
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VGdisplay: 

Um die durch »VGtransform« 
hervorgerufene Positionsverän- 
derung der Objekte sichtbar zu 
machen, wird »VGdisplay« be- 
nótigt. Diese Funktion hat nur 
einen Parameter vom Type 
Bool, der angibt, ob der Bild- 
schirm gelöscht werden soll 
(TRUE) oder nicht (FALSE). 

Zum Abschluß der Funktio- 
nen von »VG« noch einige Wor- 
te zum Koordinatensystem. Der 
auf dem Bildschirm sichtbare 


‚ Teil des Koordinatensystems ist 


normiert und liegt im X-Intervall 
von -1.0 (links) bis 1.0 (rechts) 
sowie im Y-Intervall von -1.0 
(oben) bis 1.0 (unten). Die Koor- 


Zum 
Koordinaten- 
system 


dinaten der Punkte sollten sich 
in diesem Bereich befinden. 

Um Ihnen die Anwendung 
von »VG« zu erleichtern, finden 
Sie in Listing 3 das Demopro- 
gramm »VGTEST.C«. Dieses 
Demo benötigt die Daten in Ta- 
belle 4 als ASCII-File. Geben 
Sie bitte diese mit einem Editor 
ein (die Zahlen jeweils mit ei- 
nem Leerzeichen voneinander 
getrennt, am Ende jeder Zeile 
ein RETURN). 

Im ersten Teil des Pro- 
gramms wird ein Schriftzug in 
einer vorgegebenen Form be- 
wegt. Im zweiten Abschnitt 
kann die Animation mit Hilfe der 
Maus beeinflußt werden. Dabei 
werden die mit der Maus er- 


CE DE EHER 
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УЧЕТА 


zeugten Bewegungen nicht di- 
rekt umgesetzt: die Objektbe- 
wegung ist auf die zuvor er- 
zeugten, »objektunabhängi- 
gen« Matrizen angewiesen. Die 
ermöglichen auch die Zusam- 
menfassung von beliebig vielen 
Matrizen zu einer Bewegungs- 
bibliothek. Diese können Sie 
dann auf verschiedene Objekte 
anwenden. 

Sie werden sehen, »VG« wird 
sehr bald zu einem Werkzeug 


TTT 
I VG - Vector Graphics І 
хе кекке) 
Heiko ehting 
Dirk } 
Berlin / Cuxhaven 
ТТУ, 


#include "vg.h” 


ULONG mask=0; 
struct VGColor VGDefai 
Dep, Dap, Dep, Dt, Oxf, 
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werden, das Sie nicht mehr 
missen wollen. Nutzen Sie sei- 
ne fantastischen Fähigkeiten 
und begeben Sie sich auf den 
Weg in neue Welten... so 


Heiko Schlichting studiert Biochemie in Berlin 
und arbeitet als freier Mitarbeiter für Zeitschrif- 
ten des Markt & Technik Verlages. Sie können 
ihn erreichen über unsere Verlagsanschrift 
(Markt &Technik Verlag AG, Redaktion Son- 
derhefte, z.Hd. Heiko Schlichting, Hans- 
Pinsel-Straße 2, 8013 Haar). 


rs[32] = | 
f,0x0,0x0,0x0,0xf,0x0, 


0x0,0x0,0xf,0x9,0x9,0x9,Oxf,0xf,0x0,0x0,0x6,0xd, 
0xc,Ox1,0xf,0xc,0x8,0x0,0x0,0xd,0xb,0xf,0x9,0x0, 
Oxc,Oxc,0xc,0x6,0xf,Oxe,0xd,0x0,0x0,0x0,0xb,0xb, 
0хҒ,Оха,0хс,0х6,0х1,0х7,0хҒ,0х4,0х0,0х8,0хе,0х0, 
0x9,0x1,0xf,0x1,0xf,0xb,0xf,0x8,0x0,0x2,0xc,0x0, 
0xd,0xb,0x9,0x6,0xc,Oxe,0xa,0x8,0x7,0xb,0xf,0x0, 
0x0,0xb,0x1,0x7,0x7,0x7,0x3,0x3,0x3,0x5,0x5,0x5 |; 


struct NewScreen VGnewscreen = | 0,0,320,200,2,1,2, 


t GfxBase *GfxBase; 


Listing 1. 


NULL, CUSTOMSC! 
NULL, (UBYTE *)"",NULL,N 


uitionBase *IntuitionBase; 


Mit »VG« erwecken Sie Ihre Spiele zum Leben 


Fortsetzung auf Seite 140. 


Von Klaus Sonnenleiter 


assen Sie sich nicht von 
dem verkohlen, was an- 
dere Leute auf ihre Fah- 
nen geschrieben haben. Für Ih- 
re individuellen Anforderungen 
brauchen Sie speziell angepaB- 
te Lósungen. Auch wenn Sie 
immer wieder von selbster- 
nannten Gurus anderes. 2и hö- 
ren bekommen, gibt es keine 
Universalsprache, die für alle 
Aufgaben geeignet ist. 
Natürlich ist es verlockend, 
einem eindeutigen Wegweiser, 
beispielsweise dem Rat eines 
guten Freundes ‚oder einer 
Fachzeitschrift, zu folgen. Bei 
der babylonischen Sprachver- 
wirrung im Bereich der Pro- 
grammiersprachen ist meist je- 
de kleine Hilfe ein willkomme- 
ner Richtungsanzeiger. An- 
dernfalls fürchtet man, sich all- 
zu schnell zu verirren, im 
Dschungel der diversen Pas- 
cal- und Modula-, C- und As- 
sembler-, Lisp- und Prolog-, 
Fortran- und Basic-Dialekte. 
Doch was dem Einsteiger 
recht ist, ist dem Profi billig. Er- 
bitterte Grabenkämpfe herr- 
schen zwischen Verfechtern al- 
ler Programmiersprachen. Ver- 
stehen Sie sich auch als Glau- 
benskrieger unter der Fahne 
»Ihrer« Programmiersprache? 
Das Computer-Nirwana wer- 
den Sie so nicht erreichen. Ehr- 


licherweise müssen wir einge- 
stehen,.daß auch wir den Weg 
dorthin nicht kennen, aber ei- 
nes ist gewiß: Den Gurus Glau- 
ben zu schenken, ist der sicher- 
ste Weg in den Absturz. 

Jeder Programmierer hat sei- 
ne Vorlieben und sich in einer 
Fremdsprache auszudrücken, 
bedeutet meist mehr Mühen als 
die Mángel der »eigenen« Spra- 
che zu umgehen. 

Dennoch: Oft genug ist es är- 
gerlich, wenn Sie Listings nur 
deshalb nicht verwenden kón- 
nen, weil sie in einer Sprache 
geschrieben sind, die Sie nicht 
verstehen. 

Wir wollen Ihnen auf den fol- 
genden Seiten Hinweise ge- 
ben, wie Sie diese Schwierig- 
keit umgehen kónnen. Sie fin- 
den zu den wichtigsten Pro- 
grammiersprachen (C, Modula 
und Basic) wertvolle Richtli- 
nien, mit denen Sie Programme 
dieser Sprachen in »Ihre« kon- 
vertieren können. Natürlich 
können diese nie perfekt sein. 
Aber sie sind der erste Schritt 
auf dem Weg zum Verständnis 
des jeweils anderen Lagers. so 


Von Frank Staudte 


odula und C sind die 
wichtigsten auf dem 
Amiga verfügbaren 


Hochsprachen. In vielen Bü- 
chern und Zeitschriften finden 
Sie Programme, die in einer 
dieser Sprachen veröffentlicht 
sind. Natürlich brauchen Sie 
nicht in beiden Sprachen zu 
programmieren, um Nutzen 
aus diesen Programmen zu zie- 
hen. Besser ist es, wenn Sie 
weiterhin in »Ihrer« Sprache 
programmieren. Sie sollten 
dann allerdings die jeweils an- 
dere Sprache lesen können. 
Wie Sie Programme zwischen 
diesen Welten austauschen, er- 
fahren Sie im folgenden Artikel. 

Bei der Programmierung des 
Amiga sind einige Grundkennt- 
nisse in С fast lebensnotwen- 
dig. Modula ist wegen seiner 
steigenden Beliebtheit immer 


MODULE ProgrammName; 
FROM BibName IMPORT 
Proct, Consti, Тур1; 
TYPE 

NeuerType = Anylype; 
CONST 

MyConst = Irgendwas; 
VAR 

MyVariable: Type; 
PROCEDURE MyProc 
(TestMe:Typet);Type2; 
BEGIN 

« Procedure-Code » ; 
END MyProc; 


BEGIN 
« Programm-Code » ; 
END ProgrammName. 


cecode angegeben werden 
muß, was bei C nicht der Fall ist. 
Dieser Unterschied ist noch 
relativ unbedeutend, bei den 
weiteren handelt es sich dage- 
gen um konzeptionelle Unter- 
Schiede. 

Direkt nach dem Modulna- 
men steht in Modula die Import- 
Liste, die dazu dient, dem Com- 
piler die sogenannten externen 
Referenzen (Namen, die er in 
anderen Files als dem aktuel- 
len Sourcecode findet) zu er- 
kláren. In C wird hier für die 
Pre-Prozessoranweisung » #in- 
clude« benutzt. Der Unter- 
schied ist, daß es sich bei #in- 
clude um ein Einbinden von 
»Textbausteinen« in den Quell- 
text handelt, wáhrend in Modu- 
la nur die Referenzen definiert 
werden und erst beim Linken 
der - vorher schon compilierte - 
Code eingebunden wird. 

In der Praxis heißt das, daß 
aus den beiden Modula-Zeilen 


# include < directory/filename.h > 


typedef NeuerTyp IrgendeiriTyp 


#define MyConst = Irgendwas; 
Type MyVariable; 
Type2 MyProc(TestMe) 


Туре1 TestMe; 

| 
<Procedure-Code>; 
| 
<Programm-Code>; 


] 


Tabelle 1. Eine Gegenüberstellung der Programmskelette 


für C und Modula 


häufiger als Source-Code in 
Büchern und Artikeln zu finden. 

Leider sind die C- und Modu- 
la-Compiler für den Amiga nicht 
objekt-kompatibel. Das bedeu- 
tet, daß keine Möglichkeit be- 
steht, Programmteile, die in Mo- 
dula formuliert sind, mit C-Mo- 
dulen zu verbinden. Da die bei- 
den Hochsprachen sich von der 
Struktur her sehr ähnlich sind, 
kann man ein Programm der ei- 
nen Sprache aber relativ leicht 
verstehen und in die andere 
übertragen. Sie müssen dazu 
nur die wesentlichen Unter- 
schiede der beiden Sprachen 
kennen. 

Der erste kleine Unterschied, 
der bei der direkten Gegen- 
überstellung (siehe Tabelle 1) 
auffällt, ist, daß bei Modula der 
Name des Programms im Sour- 
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FROM Exec IMPORT Node; 
FROM Dos IMPORT old 
File; 


folgende C-Zeilen werden: 


#include<exec/nodes.h> 
#include<dos/dos.h> 


Wenn Sie wissen wollen, wel- 
che Struktur in welchem »Hea- 
der« zu finden ist, würde ich 
jedem Programmierer das 

»ROM-Kernel-Reference-Ma- 
nual: Libraries & Devices« vom 
Addison-Wesley-Verlag ans 
Herz legen: Dort sind im An- 
hang alle Include-Files aufge- 
führt. Die Endung nach dem Fi- 
lenamen sagt aus, um was für 
eine Art von Quellcode es sich 
handelt: 

».H« bezeichnet ein soge- 
nanntes »Header-File«, wie es 


Konvertierung zwisc 


Brücke zwisch 


Programme von einer Sprache 
ist oft nicht ganz einfach. Wir 


am häufigsten für die Bibliothe- 
ken benutzt wird. Der Inhalt der 
».H«-Files wird in Modula іп den 
entsprechenden Bibliotheks- 
modulen (DEFINITION MODU- 
LE) definiert. In Listing 1 finden 
Sie ein Beispiel für Bibliotheks- 
module in beiden Sprachen. 

Mit ».C« kann ein komplettes 
C-Programm als Source-Code 
eingebunden werden. Es han- 
delt sich dabei meist um Routi- 
nen, die häufig benötigt wer- 
den. Modula bietet dieses Fea- 
ture nicht, man kann dies aber 
mit jedem guten Editor selbst 
machen. 

Viel interessanter ist aber die 
dritte Móglichkeit: In Files mit 
der Endung ».O« sind vorcompi- 


für die Konvertierung 


schied zwischen Groß- und 
Kleinschreibung. In C werden 
Konstanten mit einer weiteren 

Pre-Prozessoranweisung 
(»#define«) dem Compiler zu- 
gänglich gemacht. 


Zuweisungen = 
Gleichmacherei? 


Wie Typen von Modula nach 
C oder zurück übersetzt wer- 
den, entnehmen Sie Tabelle 2. 
Bei jedem übersetzten Typ soll- 
ten Sie sich jedoch Gedanken 
dazu machen, wofür er verwen- 
det wird und ob er von den ent- 
sprechenden Prozeduren als 


С-Тур Modula-2-Typ 


int INTEGER 
long int 
unsigned int 
unsigned long int 
Byte 

UByte 


float 

I» AMIGA C-Typen «/ 
WORD 

LONG 

ULONG 

BYTE 

APTR 

BPTR 

BOOL 


LONGINT 
CARDINAL 
LONGCARD 
Exec.Byte 
Exec.UByte 
REAL / FFP 


CARDINAL 

LONGINT 

LONGCARD 

BYTE 

ADDRESS 

BPTR erst ab M2c V3.2 enthalten 
BOOLEAN 


Tabelle 2. Die wichtigsten Typen von C und Modula 


gegenübergestellt 


lierte Routinen enthalten. In 
Modula muß dazu ein DEFINI- 
TION und IMPLEMENTATION 
MODULE erzeugt werden. 
Konstanten werden in Modu- 
la im Deklarationsteil (nach IM- 
PORT, vor BEGIN des Haupt- 
programms) definiert. Das 
Schlüsselwort »CONST« sagt 
dem Compiler, daß nun folgen- 
de Namen Konstanten mit dem 
dahinterstehenden Wert sind. 
Ebenso wie bei den Variablen 
macht Modula einen Unter- 


Ubergabeparameter akzeptiert 
wird. 

Eine Zuweisung (Var! Jet 
gleich« Var2) unterscheidet sich 
in den beiden Programmier- 
sprachen kaum: 


с Vari = Var2; 
MODULA Магі := Var2; 


Dies steht im Gegensatz zu 
einem Vergleich. Letztere wer- 
den etwas weiter unten bei den 
Schleifen erklärt. 
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hen Modula und C 


en den Welten 


in die andere zu übersetzen, 
vermitteln Ihnen das Know-how 


zwischen Modula und C. 


Ein wichtiges Strukturele- 
ment beider Sprachen sind Zei- 
ger auf Variablen. Eine Dekla- 
ration als Zeiger, beispielsweise 
auf eine Screen-Struktur, hätte 
folgendes Aussehen: 


с struct Screen . 
*MyScreen; 

MODULA MyScreen: 
POINTER TO 
Screen; 

oder MyScreen: 


Intuition.ScreenPtr; 


Die zweite Version in Modula 
ist möglich, da man auch Typen 
aus einer Bibliothek importie- 
ren kann, die schon als Zeiger 
(in unserem Fall auf einen 
Screen) definiert sind. 

Die Adresse einer Variable 
wird folgendermaßen ermittelt: 


Modula Addr := ADR(Var); 
wobei ADR() aus 
dem Standard- 
Modul SYSTEM 
importiert werden 
muß. 

с Addr = &Var; 


Die Initialisierung von kom- 
plexen Strukturen ist in C denk- 
bar einfach gelóst worden (die 
einzelnen Felder bei der Defini- 
tion initialisiert - siehe unten). 
struct NewScreen 

MyNewScreen = 


In Modula dagegen bleibt 
keine andere Lösung, als die 
Struktur in einer eigenen Proze- 
dur zu initialisieren. Dazu ver- 
wenden Sie am einfachsten fol- 
gende Schreibweise: 


WITH MyScreen DO 
leftEdge :- 0; top 
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Edge := 0; width : 
= 100; 
height := 200; 


END 


Die Modula-Anweisung 
YourSereen := MyScreen‘; 


weist der  Verbund-Variable 
YourScreen vom Typ »Intui- 
tion.Screen« den Inhalt der Va- 
riablen zu, auf die der Zeiger 
»MyScreen« zeigt. Das Dach 
hinter MyScreen sorgt dafür, 
daß nicht der Zeiger selbst, son- 
dern die entsprechende Varia- 
ble angesprochen wird (Derefe- 
renzierung). Dies erreichen Sie 
in С folgendermaßen: 


YourScreen = xMySereen; 


Man kann die beiden Aus- 
drücke auch umdrehen, 
(»MyScreen) := YourScreen«) 
solange die Typen der Varia- 
blen übereinstimmen. 


Mut zum 
neuen Typ 


In Modula wandeln Sie eine 
Variable vom Тур ADDRESS 
mit folgender Zeile in den Typ 
POINTER TO Screen um: 


MyScreenPointer := 
SereenPtr(MyAddress); 


wobei »MyScreenPointer« vom 
Typ ScreenPtr ist, und dieser 
importiert werden sollte. 

Das Ganze sieht in C etwas 
anders aus: 


MyScreenPtr = (struct 
Screenx )MyAddress; 


Das gleiche gilt auch von ei- 
ner Sorte Zeiger zur anderen. 
Bedenken Sie jedoch, daß dies 
nur bei zuweisungskompati- 
blen Typen gilt, beispielsweise 
Zeigern oder wie INTEGER (int) 
zu LONGINT (long). Für alle an- 
deren Konvertierungen gibt es 
in Modula die »Holzhammer«- 


SPRACHEN 


Printf()- 
Operator 


InOut-Prozedur 


Bedeutung 


\n WriteLn(); 


M Write(ASCII.tab); 


\r Write(ASCll.cr); 


\b Write(ASCIl.bs); 
\f Write(ASCIl.ff); 


Beginnt eine neue Zeile. 
Zum náchsten Tabulator. 
Geht zum Anfang der 
aktuellen Zeile 

(carriage return) 

Lóscht ein Zeichen 
(Backspace) 

Neue Seite. (Form Feed) 


Das Modul ASCII stellt dem Modula-2 Programmierer alle (Steuer)Zei- 
chen zur Verfügung. So kónnen Sie alle Feinheiten von »C« simulie- 


ren. 


printf()- 
Formelement 


InOut-Prozedur 


Zu lesender Wert 


Read()/ Write() 
Readint()/ 
Writelnt() 
ReadString()/ 
WriteString() 
ReadOktal()/ 
WriteOktal() 
ReadHex()/ 
WriteHex() 
ReadCard()/ 
WriteCard() 


Einzelner Buchstabe (CHAR). 
Zahl ((LONG)INTEGER). 


String (ARRAY OF CHAR). 
Oktal-Zahl (INTEGER). 
HexaZahl (INTEGER). 


Zahlen ohne Vorzeichen 
((LONG)CARDINAL) 


Folgende Prozeduren stammen aus den Modulen LongReallnOut / 
FFPInOut 


% ReadReal()/ 
WriteReal() 


%e dto. 


Gleitpunktzahlen 
(REAL / FFP) 
dto. 


Ein »I« als Zusatz in C bei %а, You, Yoo, %x führt zu einer Long-Zahl. 
In Modula-2 sind diese zuweisungskompatibel. Das heiBt es wird kei- 


ne eigene Prozedur benötigt. 


Tabelle 3. »printf()« oder »WriteString«? 


Methode mit Hilfe der Prozedur 
»CAST()«, die aus SYSTEM im- 
portiert werden kann. 

In C gibt es nur eine Möglich- 
keit der Umwandlung: 


(typ) (Variable) 
also 


VarTypLong = 
(long) (VarAndererTyp) 


Die Systembibliotheken sind 
unbestreitbar eines der wichtig- 
sten Hilfsmittel bei der Pro- 
grammierung des Amiga. Aber 
gerade hier herrscht zwischen 
Modula und C ein groBer Unter- 
schied: 

Um in C auf eine Bibliotheks- 
routine zugreifen zu können, 
muß die Library geöffnet wer- 
den (dies gilt für alle außer der 
Exec-Library). Deshalb findet 
man oft am Anfang von Pro- 
grammen den Aufruf wie 


MyGfxBase = ( struct 
GfxBase x) 

OpenLibrary( "graphics. 
library”,0) 

oder ähnliches. Darum muß 


sich ein M2Amiga-Program- 
mierer nicht kümmern. Diese 


Arbeit besorgt das sogenannte 
»ARTS« (Amiga Run-Time Sy- 
stem, das Laufzeit-System des 
Compilers). Wer unbedingt 
möchte, kann dies natürlich 
auch in Modula selbst überneh- 
men. 

Jede Bibliotheksroutine, die 
Sie in Modula benutzen möch- 
ten, importieren Sie vorher mit 
der »FROM...IMPORT...«-An- 
weisung. Ein Beispiel für Bi- 
bliotheksaufrufe finden Sie in 
Listing 2. 

Modula und C benutzen für 
einen Bibliotheksaufruf gele- 
gentlich unterschiedliche Ty- 
pen (sowohl für die Parameter 
als auch für den Rückgabe- 
wert). Dies kann bei der Konver- 
tierung sehr ärgerlich werden, 
zumal Ihnen kein anderer Weg 
bleibt, als jedesmal im Compi- 
ler-Handbuch nachzuschla- 
gen, welcher Typ der richtige 
ist. 

Einige Routinen sind in Mo- 
dula anders definiert als in C. 
So erhalten Sie als Rückgabe- 
wert für DolO() іп C einen Wert, 
der angibt, ob ein Fehler aufge- 
treten ist. Eine Variable »error« 
ist aber auch im Verbund der 
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SPRACHEN 


Variable des Requests enthal- 
ten, den Sie ausführen (Re- 
quest.error). Darum wurde in 
Modula dieser Rückgabewert 
weggelassen. Auf diese Fein- 
heiten sollten Sie bei einer 
Übertragung sehr genau ach- 
ten. Es erspart Ihnen viel Arger. 

Bei der Ein- und Ausgabe 
verwenden beide Sprachen 
grundlegend unterschiedliche 
Konzepte: printf und scanf() 
sind im Standard der Sprache 
C enthalten. Modula kennt hier- 
für keinen vergleichbaren Stan- 
dard. Bei allen Modula-Ent- 
wicklungssystemen (auch auf 
anderen Computern) wird es 
stattdessen die Module »InOut« 
und »FileSystem« geben. InOut 
behandelt die Bildschirm-Ein/ 
Ausgabe und FileSystem erle- 
digt die Kommunikation mit ex- 
ternen Speichermedien. 

Dabei gilt es, einen wichtigen 
Unterschied zu beachten: 
printf() und scanf() können alle 
Daten-Typen (Buchstaben, 
Zahlen, etc.) schreiben bzw. le- 
sen, Sie geben den Typ einfach 
als Argument an. In Modula 
sind in InOut verschiedene Pro- 
zeduren für jeden Zweck vor- 
handen. Welche Angabe in 
printf()/scanf) mit welcher 
Write/Read-Procedure zu er- 
setzen ist, erkennen Sie aus Ta- 
belle 3. 

Ein häufiges Konvertierpro- 
blem ist das interne Format von 
Zeichenketten (Strings). Varia- 
blen vom Typ String sind in Mo- 
dula als ARRAY OF CHAR defi- 
niert (parallel dazu in C: 
»char[]«). Sowohl in C als auch 
in Modula werden Strings auto- 
matisch mit einem abschlie- 
Benden Null-Zeichen (0C) be- 
grenzt. 

Hier beginnt jedoch der Un- 
terschied: Da man in C ein Feld 
auch »offen« deklarieren kann - 
ohne anzugeben, wie viele Ein- 
tráge das Feld maximal haben 
darf - ist das abschlieBende 
Null-Zeichen immer Bestand- 
teil des Strings. 

In Modula muB jedoch ein 
Feld immer begrenzt sein (ein- 
zige Ausnahme: Parameter- 
übergabe). Wenn ein Feld mit 
79 Eintrágen definiert und auch 
mit 79 Elementen »bis zum 
Rand« gefüllt ist, hat der Compi- 
ler keinen Platz mehr, um das 
»0C« anzuhängen. 

Wozu der Aufstand, werden 
Sie sich fragen. Wenn in einem 
C-Programm eine Variable »of- 
fen« deklariert wird, und es ist 
nicht ersichtlich, wieviel Eintrá- 
ge maximal eingesetzt werden, 
so bleibt Ihnen in Modula nur 
der Weg über einen generi- 
schen Datentyp. Solche sind in 
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Modula nicht vorgesehen, es 
existieren jedoch Implementa- 
tionen, beispielsweise auf den 
AMOK-Disketten. 

AuBerdem sind die Zugriffe 
auf einige Betriebssystem- 
Routinen entsprechend ange- 
paßt. Ein gutes Beispiel ist die 
OpenDevice()-Funktion. Wäh- 
rend in C als Device-Name ein 
beliebiger String akzeptiert 
wird, muß in Modula hier die 
Adresse dieses Strings ange- 
geben werden. Auf die gleiche 
Weise arbeiten alle System- 
funktionen, denen ein String 
als Parameter übergeben wer- 
den muß. 


Von Zweigen 
und Schleifen 


Die einfachste Form einer 
Programmverzweigung ist das 
»IF«-Statement. Sie werden in 
jeder Programmiersprache ein 
ähnliches Element finden. Die 
Konvertierung ist daher denk- 
bar einfach. 

Aus der C-Verzweigung: 


if (werti == wert2) 
do. something(); 
else do something. 
else(); 


werden die Modula-Zeilen: 


/* Sub-Routine: IncludeMe */ 


IF (werti - wert2) THEN 
do something() END; 

Soll das C-Programm mehre- 
re Anweisungen nach der Be- 
dingung enthalten, so muß ein 
Block gebildet werden. Dies er- 
reichen Sie auf folgende Weise: 
if (werti == wert2) 

[ /x Block beginnen! x/ 

do. this(); 

do_that(); 

] /x Block beenden x/ 
else 

{ /x Block beginnen x/ 

this. else(); 

that else(); 

] /x Block beenden x/ 

Derselbe Block (einschließ- 
lich ELSE-Zweig) sieht in Modu- 
la nicht viel anders aus: 

IF Werti - Wert2 THEN 
do. something(); 

(x Egal, ob eine oder . 
mehrere Zeilen! x) 
ELSE 

do. something else(); 

(ж Egal, ob eine oder 
mehrere Zeilen! x) 

END; 

Sie kónnen das »else«-State- 
ment selbstverstándlich auch 
weglassen. 

Die Bedingungen einer Ver- 
zweigung (oder einer Schleife) 


MyExternProc() /* Compilieren, NICHT linken */ 
[ /* kopieren: Z.B. RAM:IneludeMe.o %/ 


« PrgCode» ; 


/* Hauptprogramm */ 
#include “RAM: IncludeMe.o” 


main() 


MyExternProc() ; 


(* Definition des zu importierenden Files *) 


DEFINITION MODULE IncludeMe; 
PROCEDURE MyExternProc() ; 
END IncludeMe. 


(* Implementation des zu importierenden Files *) 


IMPLEMENTATION MODULE IncludeMe; 


PROCEDURE MyExternProc(); 
BEGIN 
<Procedure-Code>; 
END MyExternProc; 
END IncludeMe. 


(* HauptProgramm *) 
MODULE HauptProgrammm; 


FROM IncludeMe IMPORT MyExternProc; 


BEGIN 
MyExternProc(); 
END HauptProgramm. 


Listing 1. »Import-Export« versus »Include« 


kónnen in beiden Sprachen 

auch mit Hilfe eines logischen 

Operators verknüpft werden. 

In Modula: 

IF ((Bedingung1) AND 
(Bedingung2) OR 
(Bedingung3)) THEN 
DoIt(); END; 

In C: 


if (bedingungi && 
bedingung2 Il 
bedingung 3) do it(); 


Sie schreiben also in Modula 
die Wirkungen der Operatoren 
aus, wáhrend in C die Kürzel 
benutzt werden. Nicht zuletzt 
ist diese Schreibweise verant- 
wortlich für den schlechten Ruf 
von C in bezug auf die Lesbar- 
keit. 

Bitte beachten Sie: Mit »Be- 
dingung« meinen wir immer 
das Ergebnis einer logischen 
Operation: »Wert1 > = Wert2« 
oder áhnliches. 


Nein, Nein, Nein 
(oder doch?) 


Um das Gegenteil einer Aus- 
sage zu erhalten, kann in C ein 
Ausrufezeichen (»!«) vor die 
Klammer mit der Bedingung 
gesetzt werden. 


if !(bedingung) do it; 


In Modula erreichen Sie den 
gleichen Effekt durch das Wort 
»NOT«. 

IF NOT (Bedingung) THEN 
DoIt() END; 


Für stándig sich wiederho- 
lende Aufgaben verwendet 
man im allgemeinen eine 
Schleife. Um beispielsweise 30- 
mal eine Zahl zu erhóhen, 
schreiben Sie folgendes: 

In Modula 


FOR i:=0 TO 29 BY 1 DO 
INC(Zahl); (« erhóhe 
Zahl um eins. x) 

END; 

In C 

for (1=0;1<29;1++) 

Zahl = Zahl +1; 


Die Anweisung »BY 1« in Mo- 
dula ist nicht notwendig, da 1 
immer als Schrittweite vorein- 
gestellt ist. In C müssen Sie da- 
gegen stets die Schrittweite an- 
geben. 

Bei der for-Schleife in C gel- 
ten die gleichen Regeln, wie 
beim if-Statement: Soll nach 
der Schleifenanweisung nur ei- 
ne einzige Zeile erscheinen, so 
brauchen Sie dafür keinen 
Block anzulegen. Bedenken 
Sie aber, daß Ihr Sourcecode 
durch einen Block übersichtli- 
cher wird. 
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Amiga 
Sonderheft 7: 


Reflex (siehe Abb. unten) 

Das neueste Projekt von Arno Gölzer. 
»Reflex« ist der Nachfolger der belieb- 
ten Billardumsetzung. Lassen Sie sich 
von einer einzigartigen Spielidee und 
der tollen grafischen Umsetzung 
begeistern. Beschreibung auf Seite Off. 


Noch mehr starke Spiele... 

Ob Action- oder Strategiespiel - hier 
finden Sie alles, was das Spielerherz 
begehrt. 

»Fast Freddie« 

Die Beschreibung dieses Actionspiels 
finden Sie auf Seite 86 


»Memory« 

Eine interessante grafische Umset- 
zung für Leute mit gutem Gedächtnis. 
Beschreibung auf Seite 97 


f Technik 


Zeitschriften - Bücher 
Software - Schulung 


GRAMM- 
ERVICE 


»Reactor« 

Das Strategiespiel, das auch Atom- 
kraftgegner fesseln wird. 
Beschreibung auf Seite 107 


»Schiebespiel« 

Strategisches Denken und Tüfteln ist 
bei diesem Spiel das A und O. 
Beschreibung auf Seite 88 


Vector-Grafik-Library 

Nutzen Sie die ganze Faszination der 
Vektor-Grafik. Mit dieser Bibliothek 
bauen Sie Vector-Grafiken auf einfache 
und schnelle Weise in Ihre Programme 
ein. Der Vorteil: Es wird nur wenig Spei- 
cherplatz und Rechenzeit verbraucht. 
Beschreibung auf Seite 22ff. 

Zwei Disketten 


Bestell-Nr. 45907 


DM 34,90* 


sFr 29507/05 349,-* 


Weitere Angebote 
auf der Rückseite! 


IGA 


Sie suchen hilfreiche 
Utilities und professio- 
nelle Anwendungen für 
Ihren Computer? Sie 
wünschen sich gute Soft- 
ware zu vernünftigen 
Preisen? Hier finden Sie 
beides! 

Unser stetig wachsendes 
Sortiment enthált interes- 
sante Listing-Software 
für alle gängigen 
Computertypen. Jeden 
Monat erweitert sich 
unser aktuelles Angebot 
um eine weitere interes- 
sante Programmsamm- 
lung für jeweils einen 
Computertyp. 

Bei Fragen zu Bestellung 
und Versand der 
Programmservice- 
Disketten wählen Sie 


itte: 
Telefon (089) 46 13-232. 


Bestellungen bitte nur gegen 
Vorauskasse an: Mark! & lechnik 
Verlag AG, Buch- und Software- 
Verlag, Hans-Pinsel-Straße 2 
D-8013 Haar, 

Telefon (089) 4613-0. 

Schweiz: Markt &Technik 
Vertriebs AG, Kollerstrasse 37, 
СН.6300 Zug, Telefon (042) 
440 550. 

Österreich: Markt & Technik 
Verlag Gesellschaft m.b.H 
Große Neugasse 28, 

A-1040 Wien, Telefon 

(0222) 587 1393-0 
Mierocomput-ique, Ё. Schiller, 
Göglstraße 17, A-3500 Krems 
Telefon (027 32) 74193 
MES-Versand, Postfach 15 
A-3485 Haitzendorf 
Bücherzentrum Meidling, 
Schönbrunner Straße 261 
A-1120 Wien 

Telefon (02 22) 833196 
Bestellungen aus anderen 
Löndern bitte nur schrihlich on; 
Markt & Technik Verlag AG, 

Abt. Buchvertrieb, Hans-Pinsel. 
Straße 2, D-8013 Haar. Nur 
gegen Bezahlung der Rechnung 
im voraus. 


Bitte verwenden Sie für 
Ihre Bestellung und 
Überweisung die beige- 
heftete Postgiro-Zahlkarte, 
oder senden Sie uns 
einen Verrechnungs- 
Scheck mit Ihrer Bestel- 
lung. Sie erleichtern uns 
die Auftragsabwicklung, 
und dafür berechnen wir 
Ihnen keine Versand- 
kosten. 


Amiga-Sonderheft 4: 

С und Assembler 

Raytracer: berechnet fantastische 3-D-Bilder. Die Grafikfä- 
higkeiten des Amiga werden eindrucksvoll genutzt. 
Sound-Effekte-Editor: Zeichnen Sie beliebige Geräusche 
mit der Maus. Der Clou: Die Sounds werden als C- 
Sourcecode gespeichert und sind leicht in eigene Pro- 
gramme zu übernehmen. 

Programmiertools: Jeweils eine mausgesteuerte Benutzer- 
oberfläche für lattice- und Aztec-Compiler. Programmieren 
wird ebenso komfortabel wie das Arbeiten mit der Work- 
bench. Eine Shell hilft bei der Vereinfachung umstándlicher 
CLI-Operationen. 

Weiterhin befinden sich auf der Diskette alle Programme 
komplett mit den jeweiligen Quelltexten, die im Inhaltsver- 
zeichnis des Amiga-Sonderhefts 4 mit einem Diskettensym- 
bol gekennzeichnet sind. 

3V/2"-Diskette für Amiga 


Bestell-Nr. 45904 DM 29,90" sFr 24,90*/8S 299 -* 


Ami onderheft 3: 
Basic, Spiele 


Broker: Erleben Sie die Faszination der Börse hautnah. 
Diese Simulation für 2 bis 4 Spieler ist einzigartig. Der Autor 
setzt seine fundierten Kenntnisse in spannendes Spielge- 
schehen um. 

Ping-Pong: Dieses Sportspiel bringt Wettkampfstimmung ins 
Wohnzimmer. Dreidimensionale Darstellung, realistische 
Soundeffekte und rasante Ballwechsel führen zu lang anhal- 
tendem Spielspaß. 

Anpfiff: Als Manager in der Fußball-Bundesliga führen Sie 
Ihr Lieblingsteam durch die Saison. Zusätzliche Spiele im 
UEFA-Cup verhelfen Ihrer Mannschaft zu Ruhm und Ihnen zu 
vielen Manager-Punkten. 

Basic-Routinen: Die Basic-Kurse im Sonderheft 3 bieten 
zahlreiche, hilfreiche Routinen. Alle dort vorgestellten Pro- 
gramme finden Sie auch auf dieser Programmservice- 
Diskette. 

Weiterhin befinden sich auf der Diskette alle Programme, die 
im Inhaltsverzeichnis des Amiga-Sonderhefts З mit einem 
Diskettensymbol gekennzeichnet sind. 

3\/"-Diskette für Amiga 


Bestell-Nr. 45903 DM 29,90* sFr 24,90*/8S 299,-* 


Amiga-Sonderheft 2: 
Grafi , Anwendung 


Object-Editor: Animierte Figuren, beispielsweise für eigene 
Spiele, entwickeln Sie mit diesem Editor auf komfortable 
Weise. Sogar mit Deluxe Paint erstellte Pinsel lassen sich 
einlesen. 

Haushaltsbuch: Mit diesem hervorragenden Anwendungs- 
programm verwalten Sie alle Einnahmen und Ausgaben auf 
übersichtliche Weise. Eine Monats- oder Jahresstatistik 
zeigt, in welchen Bereichen Sie zukünftig sparen können. 
Jetzt haben Sie Ihre Finanzen im Griff. 

Keyboard-Master: lernen Sie im Zehn-Finger-System zu tip- 
pen. Mit diesem didaktisch ausgereiften Programm ist dies 
kein Problem. Für Programmierer sind sogar Spezial- 
lektionen mit wichtigen Sonderzeichen vorhanden. 
FastLoadCopy: Dieses Tool bringt den DIR-Befehl auf Trab. 
Nach der »Operation« wird das Inhaltsverzeichnis einer 
Diskette im D-Zug-Tempo eingelesen. Zusätzlich kopiert das 
Programm Disketten und versieht diese mit dem schnellen 
Directory. 

Weiterhin befinden sich auf der Diskette alle Programme, die 


im Inhaltsverzeichnis des Amiga-Sonderhefts 2 mit einem 
Diskettensymbol gekennzeichnet sind. 

3!//"- Diskette für Amiga 

Bestell-Nr. 45802 DM 29,90* sFr 24,90*/55 299,-* 
Amiga-Sonderheft 6: 


CONTEXT: Moßgeschneidert für Ihre Texte. Traumhafte 
Geschwindigkeit dank Systemroutinen, einfache Bedienung 
und sehr gut strukturierte Bedieneroberfläche. Das sind 


OGRAMMSERVICE 


Merkmale von Context - die Textverarbeitung nach Maß. 
Beschreibung auf Seite 908. 

Kontenführung: Keine Ahnung, warum Sie noch immer nicht 
Millionär sind? Dann brauchen Sie das Programm Konten- 
führung! Beschreibung auf Seite 85ff. 

AMSpool: Machen Sie ihrem Drucker Beine! Beschreibung 
auf Seite 1378. 

Waste Hunter: Dieser Packer schafft Platz auf Ihren Disket- 
ten. Beschreibung auf Seite 140ff. 

Weiterhin befinden sich auf der Diskette alle Programme, die 
im Inhaltsverzeichnis des Amiga-Sonderhefts 6 mit einem 
Diskettensymbol gekennzeichnet sind. 

Zwei Disketten 


Bestell-Nr. 45906 DM 34,90* sFr 29,507/55 349,-* 


Die Wiederbelebung für die 
С64-Регірһегіе 


Viele Amiga-Besitzer haben noch einen С64 mit Peripherie- 
geräten zu Hause stehen. Mit ein bißchen Hard- und Soft- 
ware können Sie diese zu neuem leben erwecken und Ihre 
Daten so weiterbenutzen. Dabei ist die Bedienung wirklich 
einfach. 

Der fertig aufgebaute IEC-Handler erlaubt es, alle 
C64-Geräte wie die Floppy 1541 oder 1571, Commodore- 
MPS-Drucker und natürlich auch den C64 (zur Datenüber- 
tragung) am Amiga zu betreiben. 

Das Gesamtpaket besteht aus der fertig aufgebauten Pla- 
tine mit Verbindungskabel, der Treibersoftware auf 
31/⁄2"-Diskette sowie einer entsprechenden Dokumentation. 


Bestell-Nr. 39101 DM 79,-* sFr 71,-*155 790,-* 


Amiga 3/88 
Bildschirmfüllende Boot-Bilder 
mit allen Extras 


BootGirl: Fantastische Bilder sofort nach dem Reset. Bis zu 
32 Farben mit Color-Cycling. Die Bilder können auch 
bildschirmfüllend ohne Rand sein. Ein absolutes Muß für 
jeden Amiga-Besitzer. 

CassCover: Selbstgedruckte Kassettenhüllen geben Ihnen 
den richtigen Überblick. Einfache Bedienung macht das Ein- 
geben und Ausdrucken zur wahren Freude. 

Command: Das Programm ermóglicht die Steuerung des 
Aztec-C-Compilers mit der Maus. Keine langen Eingaben 
per Tastatur, sondern ein einziger Mausklick startet nun die 
Übersetzung. 

VideoText: Ein unentbehrliches Werkzeug für alle Video- 
Fans, die ihren eigenen Vorspann mit dem Amiga generieren 
wollen. laufbänder, verschiedene Schriften und IFF-Bilder 
sind nur einige Stichpunkte, die das Programm so interessant 
machen. 

3\/p"-Diskette für Amiga 


Bestell-Nr. 48803 DM 29,90“ sFr 24,90*/8S 299,-* 
* Unverbindliche Preisempfehlung 


Mit den Gutscheinen aus dem »Super- 
Software-Scheckheft« zu DM 149,- kön- 


Wichtig: 


nen Sie Software-Disketten Ihrer Wahl aus dem Preiswerte Super- 
Software-Angebot im Wert von DM 180,- bestellen - egal, ob diese 
DM 19,90, DM 29,90 oder DM 89,- kosten. Sie sparen DM 30,-! 
Das Super-Software-Angebot finden Sie in den Zeitschriften 
Computer Persónlich, PC Magazin Plus, Amiga-Magazin, 


Amiga-Sonderheft, 64'er-Magazin, 64'er- Sonderheft, 
ST-Magazin, PC Magazin, Happy-Computer. 

Übrigens: Die Gutscheine kónnen Sie auch übertragen oder ver- 
Schenken! 

Das Scheckheft kónnen Sie per Verrechnungsscheck oder mit 
der eingehefteten Zahlkarte direkt beim Verlag bestellen. 
Kennwort: »Super-Software-Scheckheft«, Bestell-Nr. W156 


P.S.: Bei Bestellungen bitte kein Bargeld 
einschicken! 


Bei While- und Repeat- 
Schleifen beschränken sich die 
Unterschiede auf die eben ge- 
nannten. Aufeine genauere Be- 
handlung kann daher an dieser 
Stelle verzichtet werden. 


Bitgefummel 


In C-Listings werden Sie oft- 
mals Makros mit der Pre-Pro- 
zessor-Anweisung »#define« 
finden, die ungefähr folgendes 
Aussehen haben: 


#define Mal2(x) 
(x< <1) 


Die C-Befehle » > > «und» 
< « « werden in Modula mit 
der Standard-Funktion SHIFT() 
aus dem Modul SYSTEM imple- 
mentiert, die zwei Übergabe- 
Parameter verlangt: 

Als ersten Wert übergeben 
Sie die Variable, die bitweise 
verschoben (»geSHIFTet«) wer- 
den soll (der Typ ist dabei unbe- 
deutend, Records sind jedoch 
nicht erlaubt). Der zweite Wert 
ist ein Longint-Wert. Er gibt die 
Anzahl Bits an, um die die über- 
gebene Variable verschoben 
werden soll. Ist dieser Wert po- 
Sitiv, so wird nach links (» < < 
«) verschoben, wáhrend ein ne- 
gativer Wert nach rechts (» > > 
«) verschiebt. 

Sind die bisher genannten 
»kleinen Unterschiede« noch 
relativ einfach von der einen in 
die andere Programmierspra- 
che zu übertragen, so gibt es 
doch auch Besonderheiten. 
Werden diese »Spezialitäten« 
verwendet, so ist meist keine di- 
rekte Übersetzung möglich. Es 
führt kein Weg daran vorbei, die 
Gedanken des Programmierers 
(in Form der Programmstruktur) 
nachzuvollziehen und in eige- 
ne Ideen umzusetzen. Im fol- 
genden finden Sie die wichtig- 
sten Eigenheiten kurz erklärt: 

In Modula gibt es das Kon- 
zept der »TermProcedure«. Es 
handelt sich dabei um eine Pro- 
zedur, die automatisch am En- 
de des Programmes oder auch 
bei einem unvorhergesehenen 
Ende (beispielsweise beim Auf- 
treten eines Fehler) aufgerufen 
wird. Sinnvoll ist es vor allem, 
hier eine Prozedur anzugeben, 
die eventuell geöffnete Screens 
und Windows aufräumt und alle 
Ressourcen wieder freigibt. 
Diesen Service sucht der 
C-Programmierer vergeblich! 

Die einzige Chance, dieses 
Konzept wenigstens annä- 
hernd nach C zu übertragen, 
ist, die Prozedur als eine nor- 
male C-Routine zu deklarieren, 
und in jedem nur erdenklichen 
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Falle eines möglichen Fehlers 
anzuspringen. Eine TermPro- 
cedure sollte aber so »intelli- 
gent« sein, daß sie zuerst ab- 
frägt, ob ein Screen offen ist, 
oder Speicher schon belegt 
war, bevor sie diesen freigibt. 
if !(MyScreen == NULL) 
CloseScreen(MyScreen); 
Der komplette Ablauf in Mo- 
dula: 
PROCEDURE MyCleanUp(); 
BEGIN 
IF NOT (MySereen = 
NIL) THEN CloseScreen 
(MySereen); END; 
END MyCleanUp; 


BEGIN (x Hauptpro- 
gramm x) 
TermProcedure 
(MyCleanUp) ; 


«Screen öffnen>; 


(xProgrammende, ohne 
den Screen zu schließen 
(übernimmt MyCleanUp) 
x) 
END . 


Wenn aber eine TermProce- 
dure für andere Zwecke als zum 
»Aufráumen« benutzt wird, 
kann es sehr schwierig werden. 
Da hilft nur die eigene Kreativi- 
tät, es gibt keine Tips! 


MODULE OpenMe; 


FROM SYSTEM IMPORT ADR; 
FROM Dos 


VAR 
MyFile: FileHandlePtr; 


BEGIN 


| SPRACHEN 


Hingegen kann es einem Mo- 
dula-Programmierer in einem 
C-Programm passieren, daß er 
vor der Deklaration einer Varia- 
blen das Schlüsselwort »regi- 
ster« findet. 

Dies weist den C-Compiler 
an, eine Variable nach Möglich- 
keit in ein Register zu legen, 
was die Ablaufgeschwindigkeit 
des Programms erheblich er- 
höhen kann. In Modula besteht 
keine Chance, denselben Ef- 
fekt zu erreichen! 

InC kann ein String nicht ein- 
fach einem anderen zugewie- 
sen werden. Er muß Buchstabe 
für Buchstabe »kopiert« wer- 
den. Dafür existieren Routinen, 
die dem Programmierer diese 
Arbeit abnehmen (»strcpy«). In 
Modula ist das unter genau de- 
finierten Umständen möglich 
(gleiche Länge und gleicher In- 
dexbereich). Beispielsweise ist 
MeinName := ”Frank 

Staudte”; 


in Modula durchaus zulässig. 

Sie sollten aber auch in Mo- 
dula besser die Routinen aus 
dem Modul Strings benutzen, 
um ein sicheres Gelingen zu 
garantieren. 

In C können Sie Feld-Varia- 
blen benutzen, um Speicher 
beispielsweise für einen Puffer 
zu reservieren. Dies ist in Mo- 
dula wegen der strengen Ty- 
penkontrolle nicht möglich. Es 


IMPORT Open, oldFile, FileHandlePtr; 


MyFile := Open(ADR( "SYS:S/StartUp-Sequence") ,oldFi1e); 


END OpenMe. .. 


/* Dieses Programm soll die DOS-Routine Open() aufrufen */ 
/* Dies ist ein Demo, kein lauffähiges Programm */ 


#include <exec/types.h> 
#include <dos/dos.h> 
#include <dos/dosextens.h> 


struct DosBase *DosBase; 
main() 


{ 
struct FileHandle *MyFile; 


DosBase = (struct DosBase X) OpenLibrary(DOSNAME,0) ; 


if (DosBase == NULL) exit(); 


MyFile = Open("SYS:S/StartUp-Sequence ", MODE. OLDFILE); 


] 


Listing 2. Das Ansprechen der Systembibliotheken 
sieht in beiden Sprachen sehr áhnlich aus 


bleibt Ihnen kein anderer Weg, 
als den Speicher mit einer der 
Alloc-Funktionen anzufordern 
(aus den Modulen Heap oder 
Exec). Als Größe des zu allokie- 
renden Speichers geben Sie 
die Größe der vorgesehenen 
Variable an (beispielsweise der- 
selben Variable, die in C be- 
nutzt wird): 


Buffer := SIZE(Typ); 


Modula kennt das Konzept 
der »gebundenen« Parameter 
bei der Variablenübergabe an 
eine Prozedur (sogenannte 
»VAR«-Parameter). Das bedeu- 
tet, daß der Prozedur die »Er- 
laubnis« erteilt wird, den ent- 
sprechenden Wert im Haupt- 
programm zu verändern. Wird 
also eine Variable global defi- 
niert, und dann einer Prozedur 
als VAR-Parameter übergeben, 
so ändert sich bei jeder Verän- 
derung innerhalb der Prozedur 
auch der globale Wert. 

Dies ist in C nicht so einfach 
möglich, da C ausschließlich 
Werteparameter kennt. Will 
man das gleiche Konzept in C 
realisieren, so muß der überge- 
bene Wert als Zeiger (Pointer) 
auf seinen Typ deklariert wer- 
den (sowohl lokal, als auch in 
der Routinel). Dann wird in der 
Prozedur mittels Dereferenzie- 
rung (siehe oben) auf die ei- 
gentliche Variable zugegriffen 
und deren Wert geändert. 

Wie ‚Sie sicherlich bemerkt 
haben, ist Modula für den Leser 
eines Programms etwas leich- 
ter verständlich, während in C 
der kürzere Tippweg möglich 
ist. Wir möchten jedem C-Pro- 
grammierer ans Herz legen, auf 
Statements wie »x ++=;« zu 
verzichten, falls er Wert darauf 
legt, daß irgendjemand seinen 
Source-Code entziffern kann. 

Jedem interessierten Pro- 
grammierer sei an dieser Stelle 
nahegelegt, sich ein Buch mit 
einer kompletten Sprachdefini- 
tion der jeweils »fremden« Spra- 
che zuzulegen. Diese sind rela- 
tiv günstig, und enthalten die 
wirklich benötigten Informatio- 
nen. 

Natürlich wird die Konvertie- 
rung zwischen verschiedenen 
Programmiersprachen auch 
mit den hier genannten Tips 
noch nicht zum »Spaziergang«. 
Wir hoffen aber, Ihnen damit 
beim Verständnis von Fremd- 
sprachen etwas geholfen zu ha- 
ben. so 


Frank Staudte ist einer der Gründer des Amiga 
Modula Klub Stuttgart (AMOK). Sie können 
ihn über unsere Verlagsanschrift erreichen 
(Markt& Technik Verlag AG, Redaktion Son- 
derhefte, z.Hd. Herrn Frank Staudte, Hans- 
Pinsel-Str. 2, 8013 Haar). 
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Von Jürgen Singer 


Пеп Programmierspra- 

chen gemeinsam sind 

gewisse Ргодгатт- 
strukturen, die es erlauben, ei- 
nen das gestellte Problem lö- 
senden Algorithmus unabhán- 
gig von der in der Implementa- 
tion gewáhlten Sprache zu for- 
mulieren. Die einfachste dieser 
Strukturen ist die Wertzuwei- 
sung (Variable a soll den Wert b 
erhalten). Daneben gibt es ein- 
fache Verzweigungen (meist an 
Schlüsselwórtern wie »IF« und 
»ELSE« zu erkennen), abwei- 
sende und nicht abweisende 
Schleifen (»REPEAT«, »WHILE«, 
»FOR« oder »LOOP«) und Fall- 
unterscheidungen (»SWITCH« 
oder »CASE«). 

Leider sind nicht alle dieser 
Strukturen in allen Program- 
miersprachen durch explizite 
Befehle implementiert, son- 
dern es wird manchmal nötig, 
diese Strukturen durch Kombi- 
nation anderer Befehle nachzu- 
bilden. Als Beispiel hierfür kann 
die nicht-abweisende Schleife 
dienen (siehe Tabelle 1 Punkt 
3), die zwar іп C vorhanden ist, 
in Basic aber mit Hilfe eines La- 
bels und einem bedingten 
Rücksprung simuliert werden 
muB. Auch wenn sich bei der 
Umsetzung dieser, den Pro- 
grammfluß steuernden Struktu- 
ren keine groBen Schwierigkei- 
ten ergeben, sind doch einige 
Fallstricke zu überspringen. 
Dies liegt im wesentlichen dar- 
an, daß die Programmstruktu- 
ren in C etwas flexibler sind als 
die Basic-Strukturen. Dies trifft 
sowohl für die FOR-Schleife 
(kann in C mehrere Abbruchbe- 
dingungen enthalten), als auch 
auf die Fallunterscheidung zu. 
Für letztere gibt es zwei Mög- 
lichkeiten. 

Zum einen die sowohl in Ba- 
sic als auch die in C vorhande- 
ne IF-ELSEIF-Kette. Zum ande- 
ren gibt es in C noch die »richti- 
ge« Fallunterscheidung mit 
SWITCH. Diese läßt sich in Ba- 
sic mit Hilfe einiger Labels ein- 
fach mit ON n GOTO (bzw. ON 
n GOSUB) nachbilden. Dabei 
ist jedoch zu beachten, daß im 
Fall von Basic n nur eine 
lückenlose Folge von Werten 
0,1,2,...N sein darf, während іп 
Cneinen als Fall definierten be- 
liebigen konstanten Ausdruck 
annehmen darf. 

Alles in allem läßt sich sagen, 
daß bei der Umsetzung von C- 
Listings in Basic-Listings (und 
umgekehrt) bei der Übertra- 
gung der Programmstruktur 
wohl die geringsten Schwierig- 
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keiten auftreten dürften - sofern 
sich ein Basic-Listing nicht 
durch wilde GOTO-Sprünge 
über die Regeln sinnvollen Pro- 
grammierens hinwegsetzt. 
Etwas subtiler sind die 
Schwierigkeiten, die bei Unter- 
programmen und Funktionen 
auftreten. Dies liegt zum einen 
daran, daß С zwar Funktionen, 
aber keine Unterprogramme 
kennt, während in Basic der Fall 
genau umgekehrt liegt (so man 
die selten brauchbaren Ein- 
Zeilen-Funktionen vernachläs- 
sigt). Zum anderen werden 
auch die Parameter in unter- 
schiedlicher Art übergeben: C 
übergibt an seine Funktionen 
den Wert der jeweiligen Varia- 
ble, während in Basic die Adres- 
se übergeben wird, an der sich 
der Wert befindet (Übergabe 
durch Referenz). Diese unter- 
schiedlichen Übergabemecha- 
nismen haben weitreichende 
Folgen. Weist man in einem 
Basic-Unterprogramm einer 
übergebenen Variablen einen 
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Strukturen in Basic 


Konvertierung zv 


Ungleict 


Ein groBer Teil der im AMIG 
Listings ist in den Sprachen Basic und 
ein Listing der einen Sprac 


rameter, der das Ergebnis über- 
nehmen kann. Beim Aufruf des 
Unterprogramms sollte man 
durch Setzen von Klammern si- 
cherstellen, daß die Parameter 
an eine temporäre Variable zu- 
gewiesen werden, da so die 
Werte der Parameter im aufru- 
fenden Programm nicht vom 
Unterprogramm verändert wer- 
den können. Nicht so einfach ist 
die Situation bei GOSUB-Un- 
terprogrammen in Basic, da 


Bild 1. Der Aufbau von Strukturen in Basic 


neuen Wert zu, so ändert sich 
dieser Wert auch im Hauptpro- 
gramm. In einer C-Funktion 
bleibt dagegen der Wert der Va- 
riablen im Hauptprogramm un- 
verändert. 

„ Daher ist es ratsam, bei der 
Übersetzung eines Basic-Un- 
terprogrammes in C die Para- 
meter der C-Funktion als Zeiger 
auf die jeweiligen Variablen zu 
deklarieren und beim Funk- 
tionsaufruf dann die Addresse 
dieser Variablen zu übergeben. 
Setzt man umgekehrt eine C- 
Funktion in ein Basic-Unterpro- 
gramm um, so muß man dafür 
sorgen, daß der Funktionswert 
auch zurück an das aufrufende 
Programm gelangt. Daher be- 
nótigt das Basic-Unterpro- 
gramm einen zusätzlichen Pa- 


hier alle Variablen des Unter- 
programms global bekannt 
sind. Eine Móglichkeit bei der 
Umsetzung nach C wáre, die 
entsprechenden Variablen 
ebenfalls global (also auBer- 
halb von main()) zu deklarieren, 
doch ist diese Vorgehensweise 
nicht immer wünschenswert. 
Bei GOSUB-Unterprogrammen 
gibt es daher keine allgemei- 
nen Regeln, sondern es muß je 
nach dem vorliegenden Fall 
entschieden werden. 


Werden in C-Programmen ei- 
gene Windows oder Menüs be- 
nutzt, so ist es háufig einfacher, 
auch in den entsprechenden 


Basic-Programmen die gleichen 
Betriebssystem-Routinen zu nut- 
zen, statt der eingebauten WIN- 
DOW- und MENU-Befehle. Um- 
gekehrt wird man bei der Um- 
wandlung von Basic nach C al- 
lerdings nicht umhin kónnen, 
sich für die Behandlung von 
Windows und Menüs eigene 
Funktionen zu schreiben. Auch 
die in Basic vorhandene Unter- 
brechuhgsverarbeitung sollte 
man sich in C am besten mit Hil- 
fe der Routinen der Amiga- 
Libraries erarbeiten. 

Die gróBte Schwierigkeit bei 
der Umwandlung von C nach 
Basic haben wir uns bis zum 
Schluß aufgehoben. Der Daten- 
typ »struct« ist in Basic leider 
vollkommen unbekannt, wäh- 
rend er in für den C-Program- 
mierer geradezu unverzichtbar 
ist. Doch mit Hilfe einiger kurzer 
Unterprogramme und globalen 
Variablen läßt sich auch diese 
Klippe umschiffen. Dabei soll- 
ten Sie jedoch auf folgende Ei- 
genheit achten: 

In vielen Strukturen benutzt 
man Zeiger, die entweder auf 
Strings deuten oder Strukturen 
miteinander verknüpfen (ver- 
kettete Listen). Derartige Zeiger 
kónnen in Basic nicht ohne eine 
gehórige Portion Vorsicht im- 
plementiert werden, da sich die 
Speicheradressen aller Varia- 
blen in Basic wáhrend der Lauf- 
zeit ándern kónnen. Dies hat 
natürlich zur Folge, daB ein ein- 
mal gültiger Zeiger auf eine Zei- 
chenkette nach einer derarti- 
gen Verschiebung auf alles 
mógliche zeigt, nur nicht mehr 
auf die ursprüngliche Zeichen- 
kette. Als Lósung bietet sich an, 
die Strukturen nicht im norma- 
len, von Basic benutzten Spei- 
cherbereich abzulegen, son- 
dern hierfür den Systemspei- 
cher zu. benutzen. Bild 1.ver- 
deutlicht den Aufbau von Struk- 
turen. 

Dabei sollten Sie natürlich 
bedenken, diesen Speicher- 
platz nach der Programmaus- 
führung wieder an das System 
zurückzugeben. Um uns die 
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hen C und Basic 


e Brüder 


Ладагіп veröffentlichten 
jeschrieben. Wie geht man vor, um 
n die andere umzuwandeln? 


Verwaltungsarbeit zu vereinfa- 
chen, benutzen wir zur Be- 
schaffung von Speicher am be- 
sten die Funktion »AllocRe- 
member«, die nicht nur Spei- 
cher allokiert, sondern auch 
noch eine verkettete Liste des 
belegten Speichers unterhält. 
Damit kann der gesamte beleg- 
te Speicher am Programmende 
mit einem einzigen Aufruf der 
Systemroutine »FreeRemem- 
ber« wieder freigegeben wer- 
den. Zu dieser Verwaltungsar- 
beit wird die erste globale Varia- 
ble »REMEMBER.KEY« benö- 
tigt. Wir haben für Sie eine klei- 
ne Sammlung von Unterpro- 
grammen vorbereitet, die eini- 
ge Eigenheiten von С in Basic 
implementieren (Listing 1). Da- 
mit umgehen Sie viele Wider- 
wärtigkeiten beim Konvertie- 
ren. Sie sollten aber die folgen- 
den Hinweise genau beachten. 


Definition 


Bei деп: Strukturen unter- 
scheiden wir zwei Fälle: Zum ei- 
nen muß definiert werden, wie 
die Struktur aussieht, zum an- 
deren müssen dann auch »Ver- 
körperungen« dieser Struktur 
implementiert werden. Bei der 
Definition müssen wir uns mer- 
ken, welche »Mitglieder« die 
Struktur besitzt und wo diese 
innerhalb der Struktur zu finden 
sind. Dazu dient das globale 
Feld »STRUCT.MEMBERS«, 
das den jeweiligen Abstand ei- 
nes Mitglieds vom Beginn der 
Struktur aus enthált. Das Unter- 
programm »DEFSTRUCT« setzt 
die jeweiligen globalen Varia- 
blen auf den Anfangszustand. 
Die Unterprogramme »CHAR«, 
»VOID.PTR« etc. sorgen dafür, 
daB die jeweiligen Abstánde 
vom Strukturstart eingetragen 
werden. Das Unterprogramm 
»ENDSTRUCT« überträgt diese 
Liste in den Systemspeicher, 
damit diese Informationen den 
spáteren Verkórperungen der 
Struktur zur Verfügung stehen. 
Die globale Variable »STRUCT. 
STATUS« steuert das Verhalten 
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der Unterprogramme CHAR, 
VOID.PTR etc. wie folgt: 
Werden diese Unterprogram- 
me innerhalb einer Strukturde- 
finition aufgerufen, so tragen 
sie die jeweilige Position in die 
entsprechende  Strukturliste 
ein. Werden sie dagegen au- 
Berhalb einer Strukturdefinition 
aufgerufen, so reservieren sie 
den benótigten Speicherplatz 
für den jeweiligen Eintrag. Um 
von einer Strukturimplementa- 
tion aus die zugehórige Struk- 
turdefinition zu finden, ist der 
erste Eintrag einer Implementa- 
tion immer ein Zeiger auf die 
passende Definition. Die mit 
diesen Unterprogrammen im- 
plementierten Strukturen kom- 
men von der Syntax her denen 
in C schon sehr nahe. Weniger 
erquicklich ist die Situation je- 
doch bei den Wertzuweisun- 
gen. Auch diese kónnen nur mit 
Hilfe von Unterprogrammen er- 
folgen, wobei auch noch unter- 
schieden werden muß, ob Wer- 
e von einer Variablen an eine 
Struktur übergeben werden 
sollen (ASSIGN.TO) oder umge- 
kehrt (ASSIGN.FROM). Bei die- 
sen Zuweisungen ist, wie auch 
bei den anderen Struktur- 
Unterprogrammen, zu beach- 
ten, daB keinerlei Fehlerüber- 
prüfungen unternommen wer- 
den, da diese den Programm- 
umfang doch erheblich hátten 
ansteigen lassen. Die bei- 
den Unterprogramme CSTRING 
und BSTRING dienen nur dazu, 
Basic-Zeichenketten in C-Zei- 
chenketten (diese zeichnen 
sich durch eine abschließende 
»0« aus) - und umgekehrt - um- 
zuwandeln, da alle Zeichenket- 
ten innerhalb von Strukturen 
den C-Konventionen folgen. 
Mit diesem Rüstzeug verse- 
hen, dürfte es keine groBen 
Schwierigkeiten mehr machen, 
die gängigen C-Listings in 
Basic-Programme umzuwan- 
deln. Etwas schwieriger ist al- 
lerdings der umgekehrte Fall, 
da Unterbrechungsverarbei- 
tung und andere abstrakte Kon- 
zepte in Basic eingebaut sind, 


SPRACHEN 


Amiga-Basic 


1. Einfache Verzweigung 


С (ANSI) 


IF (Bed) THEN 
(Fall 1) 
ELSE 

(Fall 2) 
END IF 


2. abweisen« 


if (Bed) | 
(Fall 1) 
else | 
(Fall 2) 


ide Schleife 


FORI = 1 TOM STEP S 
NEXT I 


for(i = 0;i < Mii += s)Í 


WHILE (Bed) 
WEND 


while (Bed) | 


3. nicht-abweisende Schleife 


REPEAT: 
IF (Bed) GOTO REPEAT 


4. Fallunterscheidung 


do { 
| while (Bed); 


IF (Bed1) THEN 
(Fall 1) 
ELSEIF (Bed2) 
(Fall 2) 


ELSEIF (BedN) 
(Fall N) 
ELSE 

(sonst) 
END IF 


if (Bed) | 
(Fall 1) 
else if (Bed2) | 
(Fall 2) 


else if (BedN) | 
(Fall N) 
else | 
(sonst) 


ON N GOTO 
CASE1,CASE2,...,CASEN 
DEFAULT: 

GOTO ENDCASE 
CASEI: .... 

GOTO ENDCASE 


CASEN: .... 
ENDCASE: 


switch (n) { 


break; 


default HO 


) 


5. Implementation von Unterprogrammen und Funktionen 


SUB UPROG(I%,L&,FI,D#) 
STATIC 


END SUB 


void uprog(short +i, long +l, 
float +f, double +d) { 
} 


SUB FCT(ERG ж, Da, L& ) 
STATIC 


ERG # шш... 
END SUB 


double erg; 
double fct( double d, long |) } 


return ....; 


) 


6. Aufruf von Unterprogrammen und Funktionen 


CALL UPROG(I%,L&,F!,D ж) 


uprog(&i, 81, 84, &d); 


CALL FCT(ERG#, (Dei, (18)) 


erg = fet(d, I); 


Tabelle 1. Die wichtigsten Elemente von C und Basic 


gegenübergestellt 


während sie in C durch Rück- 
griff auf die Systemroutinen 
»nachprogrammiert« werden. 
Da jedoch jeder Besitzer des 
Amiga über Amiga-Basic, nicht 


unbedingt jedoch über einen C- 
Compiler verfügt, ist die Um- 
wandlung von C nach Basic si- 
cherlich von größerem Interes- 
se als der umgekehrte Fall. so 
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ON BREAK GOSUB BreakHit 
' ON ERROR GOTO ReleaseMem 


' Externe Funktionen 

LIBRARY "exec.library" 

LIBRARY "intuition.library" 

DECLARE FUNCTION AllocRemember&( RememberPtr&, size&, Flagsk) LIBRARY 


' Voreinstellungen 
OPTION BASE 0 
DEFLNG а-2 


DIM SHARED SIZEOFLONG,MAX.MEMBERSÉ 
' Konstanten 

SIZEOFLONG = 4& 

MAX.MEMBERS% = 20 


' globale Variable 

DIM SHARED STRUCT .MEMBERS (MAX. MEMBERS) 

DIM SHARED REMEMBER.KEY, STRUCT.LENGTH,STRUCT. STATUS , MEMBER. NO 
STRUCT.LENGTH = 0& 

STRUCT.STATUS = 0% ' <> 0, falls innerhalb von Struktur-Defini- 
tion 

MEMBER.NO = 0% 

REMEMBER.KEY = 0% 


' Unterprogramme zum Umgang mit Strukturen 
SUB defstruct STATIC 

STRUCT.STATUS = 1& 

STRUCT.LENGTH = SIZEOFLONG ' Erster Eintrag ist Zeiger auf Strukt- 
ur-Definition 

MEMBER.NO = 1& 

FOR i% = 0 TO МАХ.МЕМВЕН5% 

STRUCT.MEMBERS(1%) = 0% 

NEXT 1% 

END SUB 


SUB endstruct( struct.name ) STATIC 
STRUCT.STATUS = 0& 
STRUCT.MEMBERS(0) = MEMBER.NO 
STRUCT.MEMBERS(MEMBER.NO) = STRUCT. LENGTH 
bytes = (MEMBER.NO+1) * SIZEOFLONG 
struct.name = AllocRemember&(VARPTR(REMEMBER.KEY) ,bytes,0) 


CopyMem VARPTR(STRUCT.MEMBERS(0)),struct.name,bytes 
END SUB 


SUB allot( instance, size) STATIC 
IF ( STRUCT.STATUS = 0 ) THEN 
instance = AllocRemember&(VARPTR(REMEMBER. KEY) ,size,0) 
ELSE 
STRUCT.MEMBERS(MEMBER,NO) = STRUCT.LENGTH 
STRUCT.LENGTH = STRUCT.LENGTH + size 
instance = MEMBER.NO 
MEMBER.NO = MEMBER.NO + 1 
END IF 
SUB 


struct( struct.name, instance ) STATIC 
size = CLNG(PEEKL(struct.name + PEEKL(struct.name) * SIZEOFLONG)) 
allot instance, size 
IF (STRUCT.STATUS = 0 ) THEN 
POKEL instance, struct.name 
END IF 
SUB 


void.ptr( instance ) STATIC 
allot instance, 4% 
SUB 


short.ptr( instance ) STATIC 
allot instance, 4& 
SUB 


long.ptr( instance ) STATIC 
allot instance, 4& 
END SUB 


SUB float.ptr( instance ) STATIC 
allot instance, 4& 
END SUB 


SUB double.ptr( instance ) STATIC 


allot instance, 4& 
SUB 


char.ptr( instance ) STATIC 
allot instance, 4& 
SUB 


short( instance ) STATIC 
allot instance, 2& 
SUB 


long( instance ) STATIC 
allot instance, 4& 
SUB 


float( instance ) STATIC 
allot instance, 4& 
SUB 


double( instance ) STATIC 
allot instance, 8& 
SUB 


char( instance, bytes) STATIC 
allot instance, bytes 
SUB 


assign.to( instance, member, value.ptr) STATIC 
struct.descr = PEEKL( instance) 
last.member = PEEKL(struct.descr) ы М 
member.offset = struct.descr + member % SIZEOFLONG 
IF member = 0 THEN 
length = PEEKL(struct.descr + last.member % SIZEOFLONG) 
CopyMem value.ptr,instance,length 
ELSEIF member < last.menber THEN 
offset = PEEKL(member.offset) 
length = PEEKL(member.offset+SIZEOFLONG) - offset 
CopyMem value.ptr,instance+offset,length 
END IF 
SUB 


assign.from( value.ptr, instance, member) STATIC 
struct.descr = PEEKL(instance) 
last.member = PEEKL(struct.descr) 
member.offset = struct.descr + member * SIZEOFLONG 
IF member < last.member THEN 
offset = PEEKL(member.offset) 
length = PEEKL(member.offset+SIZEOFLONG) - offset 
CopyMem instance+offset,value.ptr,length 
ELSEIF member = 0 THEN 
length = PEEKL(struct.descr + last.member * SIZEOFLONG) 
CopyMem instance,value.ptr,length 
END IF 
SÜB 


strepy( destptr, sourceptr) STATIC 

dp = destptr 

вр = sourceptr 

a = PEEK(sp) 

WHILE (a <> 0) 
POKE dp, a 
dp = dp +1 
8р = 8р + 1 
а = PEEK(sp) 

WEND 

POKE dp, a 


END SUB 


SUB cstring(strptr,a$) STATIC 


IF STRUCT.STATUS = 0 THEN 
size = LEN(a$) +1 
allot strptr, size 
CopyMem SADD(a$) ‚strptr,size 
POKE strptr+size-1,0 
END IF 


END SUB 


SUB bstring(a$,strptr) STATIC 


IF (STRUCT.STATUS = 0) THEN 
1-0 
WHILE PEEK(strptr+i) <> 0 
12141 
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WEND \ 
b$ = SPACE$(1) 
CopyMem strptr, SADD(b$), i 
a$ = b$ 
END IF 
END SUB 


SUB freestructs STATIC 


END SUB 


defstruct 
void.ptr piNext 

Next ; 
char  piVorname, 12% 


char.ptr piNane 
long  piID 
endstruct PersonalInfo 


defstruct 

struct PersonalInfo, glArbeiter 
rbeiter ; 

float glGehalt 
endstruct GehaltsListe 


struct PersonalInfo, pi 
struct GehaltsListe, gl 


Nach = 0% 
ID = 12345& 

Gehalt! = 2937.92 

VN$ = "Anton ”+CHR$(0) 
estring Nachname, "Meier" 


FreeRemember VARPTR(REMEMBER. KEY) , -1& 


' Beispielprogramm zum Umgang mit Strukturen in Basic 


' Äquivalente C-Formulierung 
' struct PersonalInfo | 
' struct PeronalInfo* pi- 


char piVorname[12] ; 
! char* piNane ; 
' long рії ; 
EI 

] i 
' struct GehaltsListe [ 
struct PersonalInfo glA- 


t float glGehalt ; 


struct GehaltsListe gl ; 


SPRACHEN 


assign.to pi, 
assign.to pi, 
‚"Anton”) ; 

assign.to pi, 


piNext, VARPTR(Nach) 
piVorname, SADD(VN$) 


piName, Nachname 


assign. 
assign. 


to 
to 


рі, piID, VARPTR(ID) 
gl, 


gl, 


assign.to 


glArbeiter, pi 


assign.from 
assign.from 
assign. from 
assign. from 
assign.from 
assign.from 
bstring NN$, Nachname 
bstring VN$, SADD(VN$) 

PRINT Nach, VN$, NN$, ID, Gehalt! 
FINISHED: 

freestructs 


pi, gl, glarbeiter 


Nachname, pi, piName 
VARPTR(ID), pi, piID 


END 


ReleaseMem: 
PRINT “Fehler Nummer:”, ERR 
RESUME FINISHED 


BreakHit: 
RETURN FINISHED 


glGehalt, VARPTR(Gehalt!) 


' gl.glArbeiter.piNext = NULL ; 
' strepy(gl.glArbeiter.piVorname- 
' gl.glArbeiter.piName = "Meier" 


' gl.glArbeiter.piId = 
' gl.glGehalt = 


12345 ; 
2937.92 ; 


VARPTR(Nach), pi, piNext 
SADD(VN$), pi, piVorname 


VARPTR(Gehalt!), gl, glGehalt 


Listing 1. Mit dieser Sammlung von 
Unterprogrammen erleichtern Sie sich das 
Konvertieren von C nach Basic 


Quelltextportierung von Aztec nach Lattice 


ccalc - ganz einfach? 


enngleich C zur Ver- 
einfachung der Uber- 
tragung von Quelltex- 


ten entwickelt wurde, können 
kleinere und größere Unter- 
schiede in den jeweiligen Com- 
pilerimplementationen doch 
Probleme aufwerfen, so daß ge- 
rade bei systemnaher Program- 
mierung unter Ausnutzung spe- 
zifischer Compilereigenschaf- 
ten die genaue Kenntnis beider 
beteiligter Compiler nötig ist. 
„Dieser Artikel gibt einen 
Überblick über die bei der 
Quelltextportierung von Aztec- 
C auf Lattice-C-5.0 zu erwarten- 
den Probleme. Er kann und soll 
nicht die Lattice-Compilerdoku- 
mentation ersetzen, deren 
„Kenntnis in jedem Falle voraus- 
gesetzt wird. 

Die Portierungsrichtung ist 
übrigens nicht ganz willkürlich 
gewählt: Da von Manx schon 
seit einiger Zeit nichts mehr zu 
hören war, steigen viele Pro- 
grammierer auf das wesentlich 
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Die Unterschiede zwischen den beiden 


Amiga-C-Compilern 


erschweren die Um- 


setzung von Quelltexten auf den jeweils 
anderen Compiler. 


Von Ralph Babel 


leistungsfähigere Entwick- 
lungspaket von Lattice um, wol- 
len jedoch bereits entwickelte 
Software nicht zurücklassen. 
Auch sind viele Aztec-C-Bei- 
spielprogramme - etwa dieses 
Heftes - durchaus für Lattice- 
Programmierer interessant, be- 
dürfen jedoch vor der fehlerfrei- 
en Ausführung einiger kleiner 
Modifikationen. 

Es geht daher nur um die 
Umsetzung lauffähiger Pro- 
gramme, wobei auch hier Ein- 
schränkungen bezüglich des 
Schwierigkeitsgrades zu ma- 
chen sind: Ein Arno-Gölzer- 
Programm ist sicherlich leichter 


zu übersetzen als Matt-Dillon- 
Quelltexte oder mit #asm ge- 
Spickte Leo-Schwab-Hacks. 
Die Portierung von Overlay- 
Programmen (oder die Anwen- 
dung der Aztec-Funktionen 
segload() und freeseg()), Sy- 
stembibliotheken und Geräte- 
treibern bleibt wohl erfahrenen 
Profis vorbehalten. 

Die Unterschiede zwischen 
den beiden Amiga-C-Compi- 
lern selbst (im Unterschied zu 
den im folgenden beispielswei- 
se noch zu besprechenden Bi- 
bliotheken) sind weit weniger 
bedeutend als üblicherweise 
angenommen, da Aztec eine 


Untermenge von Lattice dar- 
stellt - die umgekehrte Portie- 
rungsrichtung ist sicherlich die 


Schwierigere. Ein typisches 
Beispiel für Inkompatibilität 
stellt der Ausdruck 

a[i] = ++i; 


dar. Soll hier vor oder nach der 
Erhöhung von i die Zieladresse 
berechnet werden? Die Imple- 
mentatoren von Aztec und Latti- 
ce waren sich zumindest in die- 
sem Fall nicht einig, und trotz- 
dem haben beide recht. 

Glücklicherweise verlassen 
sich Programmierer üblicher- 
weise nicht auf die Reihenfolge 
der Auswertung von Teilaus- 
drücken oder andere Nebenef- 
fekte, da dies allgemein als 
schlechter Programmierstil an- 
gesehen wird. 

Andere Unterschiede betref- 
fen Eigenschaften, deren Im- 
plementationen normalerweise 
in den spezifischen Include- 
Dateien versteckt sind und vom 
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Programmierer nicht beachtet 
werden müssen, etwa das off- 
setof()-Makro und seine Spe- 
zialfoom ECOFFSET aus 
<libraries/configregs.h>. 

Lediglich der neue ANSI- 
Präprozessor von Lattice-C 
kann zu Problemen führen - et- 
wa bei der Ersetzung von Para- 
metern in Strings - und sollte 
durch 


LC -co programmname 
ausgeschaltet werden. 


Include-Dateien 


Sofern das Programm nicht 
zu der seltenen Sorte gehört, 
die nach der Eingabe von 


LC -L programmname 


sofort lauffähig ist, betrifft der 
erste Schritt beider Umsetzung 
meist die Anpassung der Liste 
verwendeter Include-Dateien. 
So machen unterschiedliche 
Verkettungen - viele Include- 
Dateien ziehen weitere nach 
sich - unter Lattice-C mögli- 
cherweise die explizite Angabe 
weiterer Include-Dateien not- 
wendig, die von Aztec-C auto- 
matisch nachgeladen werden. 

So sollte - alphabetische Rei- 
henfolge hin oder her - <exec/ 
types.h> immer als erste Datei 
spezifiziert werden, beispiels- 
weise bei Arno Gölzers Pro- 
grammen in diesem Heft. Auch 
die Dateien <hardware/cu- 
stom.h> und « hardware/dma- 
bits.h> fehlen oft und machen 
sich durch Fehlermeldungen 
beim Bezeichner custom und 
solchen Konstanten, die mit 
DMA beginnen, bemerkbar. Im 
ersten Fall muB neben der 
Include-Datei zusátzlich noch 
die Anweisung 


extern struct Custom _ 
far custom; 


in den Quelltext mitaufgenom- 
men werden, da dies unter Az- 
tec-C automatisch geschieht. 
Gleiches gilt für die beiden CIA- 
Symbole »iaa« und »ciab«. 

Treten beim anschlieBenden 
Binden durch BLink nichtaufló- 
sende Referenzen mit Namen 
wie OFF. DISPLAY, . Set- 
DrPt, . SetAfPt oder . C- 
MOVE auf, so wird auBerdem 
<graphics/gfxmacors.h> be- 
nótigt. 

Da Include-Dateien üblicher- 
weise keinen Code erzeugen, 
kónnen alle genannten Dateien 
immer ohne negative Nebenef- 
fekte (von geringfügig längerer 
Übersetzungszeit einmal abge- 
sehen) eingebunden werden. 

Die Aztec-Datei <functions. 
h> enthält die Funktionsdekla- 
rationen für die Routinen der 
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Amiga-Systembibliotheken und 
muB durch das Lattice-Aquiva- 
lent <proto/all.h> ersetzt wer- 
den. Dies kann allerdings auch 
Probleme nach sich ziehen, et- 
wa wenn im Programmcode 
weitere Funktionsdeklaratio- 
nen vorkommen oder Basis- 
symbole für Bibliotheken defi- 
niert werden. Programme von 
Leo Schwab sind ein bekanntes 
Beispiel hierfür. Hier finden sich 
Zeilen wie 

void xIntuitionBase; 
void xGetMsg(); 


Da durch <prot/all.h> je- 
doch 


extern struct Intuition- 
Base xIntuitionBase; 
struct Message xGetMsg 
(struet MsgPort x); 


vereinbart wurde, erkennt der 
Compiler Widersprüche und 
meldet Fehler. Diese lassen 
sich dadurch lösen, daß die Ver- 
einbarung für Basissymbole 
den Informationen in den Proto- 
Dateien angepaßt und Funk- 
tionsdeklarationen ersatzlos 
entfernt werden. 

Bleibt noch ein besonderer 
Fall, der unter Aztec-C sehr 
häufig vorkommt: Das Pro- 
gramm scheint gar keine #in- 
clude-Anweisungen zu enthal- 
ten. Dies ist auf eine populäre 
Fähigkeit des Aztec-Compilers 
zurückzuführen, die das »Vor- 
übersetzen« von Include-Datei- 
en erlaubt. Hier werden zur Ver- 
kürzung der Übersetzungszei- 
ten einmalig alle benótigten 
Include-Dateien übersetzt und 
spáter dann nur noch die bei 
diesem ersten Durchlauf ent- 
standene Symboldatei angege- 
ben. Findet sich im Verzeichnis 
der zum Programm gehórigen 
Quelltexte keine Datei, die aus- 
schließlich aus #include-An- 
weisungen besteht, so müssen 
die notwendigen Include-Datei- 
en manuell ausfindig gemacht 
werden. 

Das Aztec-Präprozessorsym- 
bol _FUNC___ kennt übri- 
gens in Lattice-C keine Entspre- 
chung, wird aber meist ohnehin 
nur zur Fehlersuche verwendet. 


»Sie wurden 
gewarnt!« 


Solite das Programm nach 
den genannten Anderungen 
problemlos durch 


LC programmname 


übersetzt werden können 
(wenn nicht - keine Panik, es 
kommen noch wesentlich mehr 
Hinweise), so mag es den ehe- 
maligen Aztec-Programmierer 
irritieren, daß eine solche Mas- 


se an Warnungen auf ihn ein- 
prasselt. Lattice-C ist, was die 
korrekte Verwendung von Da- 
tentypen angeht, wesentlich 
aufmerksamer als die meisten 
anderen C-Compiler. Viele die- 
ser Warnungen können jedoch 
mit großer Wahrscheinlichkeit 
ohne nachteilige Folgen ein- 
fach ignoriert werden, da sie 
aus Zuweisungen (Warnung 
30) oder Übergabe (Warnung 
88) inkompatibler Zeigertypen 
resultieren. Unter einem 
M68000-Prozessor sind diese 
aufgrund des linearen 32-Bit- 
Adreßraums jedoch nicht weiter 
bedeutend und. können unter 
Lattice-C-5.02 zu einem Groß- 
teil durch die Option -cq unter- 
drückt werden. 

Neben diesen beiden War- 
nungen (Warning 30: pointers 
do not point to the same object 
und Warning 88: argument type 
incorrect) sind auch 
. warning 84: redefini- 
tion of pre-procesor 
symbol 
. warning 89: constant 
converted to required 
type 
. warning 93: no refe- 
rence to identifier 


ohne tiefere Bedeutung für die 


Lauffáhigkeit ^ eines Pro- 
gramms. 
Da Aztec-C eine fehlende re- 


turn-Anweisung in int-Funktio- 
nen nicht bemängelt (viele 
void-Funktionen werden. - 
entsprechend dem älteren 
Kernighan&Ritchie-Standard 
([2]) - ohne explizites void ver- 
einbart), können natürlich auch 
hier weitere Warnungen auftre- 
ten. «Warnungen dieses Typs 
(Warning 85: function return va- 
Іше mismatch) lassen sich 
durch die Lattice-Option -cw un- 
terdrücken. Durch Überset- 
zung mit 
LC -eqw -j841891931 
programmname 


kann man sich daher leichter 
auf die möglicherweise bedeu- 
tenden Meldungen konzentrie- 
ren. 

Meldung 30 kann übrigens 
auch als Fehlermeldung (an- 
stelle einer Warnung) auftreten, 
etwa durch Zuweisung von 
ganzzahligen Werten ungleich 
null an Zeigertypen, was unter 
Aztec-C nicht bemángelt wird. 
Anweisungen wie 
struct Custom xp - 
Oxdff000; 
ändert man daher durch einen 
expliziten »cast« wie folgt um: 
struct Custom xp - 

(void x)-xdff000; 


Auch weitere unbedeutende 
Warnungen sind móglich. 
Durch Zeilen wie 


LC -eqw -]841891931 
programme 


wurde bereits angedeutet, daß 
viele  Compilereigenschaften 
durch Kommandozeilenoptio- 
nen gesteuert werden kónnen. 
Bekanntestes Beispiel sind 
wohl die Speichermodelle, die 
die Adressierung von Code und 
Daten regeln. Wichtiger ist aber 
die Datenadressierung, die bei 
beiden relativ zum Basisregi- 
ster A4 erfolgt, was alle Daten in 
einem Segment vorausgesetzt. 
Mit 

LC -Ledn programmname 
wird aller Code und werden alle 
Daten in jeweils ein Segment 
gepackt und sämtliche De- 
bugging-Informationen (auch 
hierzu später noch mehr) ent- 
fernt, so daß ein relativ kurzes 
ausführbares Programm ent- 
steht. Sollte sich BLink trotz der 
Verwendung dieser Optionen 
noch mit der Fehlermeldung Er- 
ror 510: Reference to unmerged 
data item beschweren, so muß 
das Programm mit 


LC -b0 programmname 


übersetzt werden. Dies bewirkt 
die absolute Adressierung aller 
statischer Daten. 

Die Datenablage wird durch 
eine weitere wichtige Option 
beeinflußt: -a. Bekanntlich 
müssen auf einem Amiga alle 
Daten, die durch DMA von den 
Custom-Chips gelesen werden 
- Grafik- und Audiodaten z.B. - 
im sog. »Chip-Memory« abge- 
legt werden. Wird der Speicher 
durch das Programm angefor- 
dert, so stellt dies kein Problem 
dar, im Unterschied zu stati- 
schen Daten, die im resultieren- 
den Lademodul einer speziel- 
len Markierung bedürfen (ver- 
gleiche Literaturhinweise [1, 
Abschnitt 22.3.2]. Was unter 
Aztec-C durch die Linker- 
Option +c (auch in den Formen 
+cd oder +cdb) erreicht wird, 
erreichen Sie unter Lattice-C 
durch 
LC -adb programme 

Ist es also zunächst bedeu- 
tend, das Programm einfach 
nur lauffähig zu bekommen (oh- 
ne Rücksicht auf die Effizienz), 
so können Sie ganz plump 
durch 
LC -adb -b0 -coqwv - 
3841891931 -r0 -Ledn 
programmname 
Ihr Glück versuchen. 

Weitere Optionen werden im 
jeweiligen Zusammenhang er- 
klärt. 
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Die ersten größeren Unter- 
schiede ergeben sich, wenn 
nicht nur ganzzahlige, sondern 
auch Fließkommaabrechnun- 
gen durchgeführt werden sol- 
len. Aztec-C verwendet im De- 
fault das sog. Fast-Floating- 
Point-Format (kurz FFP), wäh- 
rend Lattice die doppeltgenaue 


IEEE-Arithmetik einsetzt. 
Wird die Datei <math.h> 
eingebunden, kommen im 


Quelltext die Datentypen float 
oder double vor oder werden 
vom Linker diverse __CX-Sym- 
bole als nicht definiert rekla- 
miert, so sind dies untrügliche 
Zeichen für Fließkommaopera- 
tionen im Quelltext. In diesen 
Fällen müssen die Include-Da- 
teien <libraries/mathffp.h> 
und <proto/mathffp> durch 
#include eingelesen und die 
mathffp.library geöffnet wer- 
den. Dies erreichen Sie durch 


struct Library Math 
Base; /x global! x/ 

Lé ,,%/ 
CloseLibrary(MathBase) ; 


- natürlich mit den zugehörigen 
Fehlerabfragen. Das Öffnen 
sollte während der Initialisie- 
rung und das Schließen in der 
üblichen »Aufräumroutine« er- 
folgen. Werden mehr als nur die 
Grundrechenarten benötigt (et- 
wa sqrt(), sin() oder atan(), so 
muß auf die gleiche Weise zu- 
sätzlich die mathtrans.library 
geöffnet werden. Das zugehöri- 
ge Basissymbol heißt hier 
MathTransBase: e 

Die Übersetzung erfolgt 
dann in beiden Fállen durch 


LO -ff -Lf programmname 


Durch den  Inline-Code 
(<proto/mathffp.h>) werden 
solche Programme relativ 
schnell. 


Bibliotheken 


Wichtiger Teil eines C-Com- 
pilers sind die Bibliotheken, die 
den Code der externen Stan- 
dardfunktionen enthalten, etwa 
für UO oder Speicherverwal- 
tung. Trotz großer Gemeinsam- 
keiten gibt es doch einige 
Aztec-Funktionen, die unter 
Lattice-C nicht oder nur in an- 
derer Form vorhanden sind. 
Nicht vorhanden sind beispiels- 
weise die Screen-Funktionen, 
die jedoch durch folgende Prä- 
prozessordefinitionen ersetzt 
werden können: 

#define ser beep() 
printf(^a") 

#define ser bat) 
printf(”\b”) 

#define scr_cdelete() 
printf(”\233P”) 
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#define scr_clear() 
printf ^\?”) 

#define scr сг() 
printf(”\r”) 

#define scr curs(row, 
col) printf( "23274; 
Фан”, (short) (row+1), 
(short) (col +1)) 
#define scr cursrt() 
printf("233C") 
#define scr cursup() 
printf(^wv") 

#define ser eol() 
printf( "233;” 
#define scr_hone() 
printf( ”\233H”) 
#define scr ldelete() 
printf( ”\233M!) 
#define scr Lë) 
printf( "204”) 
#define scr linsert 
printf( ”\233L”) 
#define ser tab() 
printf MET) 

Die Debugging-Funktionen 
zur Ausgabe auf ein serielles 
Terminal sind für Lattice-C in ei- 
ner separaten Bibliothek, « de- 
bug.lib > , enthalten, die explizit 
beim Linken spezifiziert werden 
muB: 
le -L«LIB:debug.lib 
programmname 

Aztecs dos-packet()-Funktion 
schickt ein Amiga-DOS-Paket 
an einen Handler-Prozeß und 
muB unter Lattice-C selbst ge- 
schrieben werden, was mit Hil- 
fe beispielsweise von Kapitel 21 
aus dem  Amiga-Guru-Buch 
(siehe Literaturhinweise) nicht 
weiter schwerfallen dürfte. 

Nur mit solider Kenntnis des 
Programms lassen sich die 
meist sehr system- und compi- 
lerabhángigen Anwendungen 
der Funktionsfamilie »exec()« 
und »fexec« ersetzen, die unter 
Lattice-C nicht vorhanden sind. 
»fork()« etc. haben entfernte 
Ahnlichkeiten. 

Leichter adaptierbar ist das 
Durchsuchen eines Verzeich- 
nisses mit der Funktion scdir(), 
die in der Lattice-Bibliothek 
durch das Funktionspaar 
dfind() und dnext() relativ ähn- 
lich implementiert sind, hier je- 
doch auch Amiga-DOS-Muster 
erkennt und nicht auf die MS- 
DOS-Jokerzeichen »*« und »?« 
beschránkt ist. 

Wichtiger Teil der Bibliothe- 
ken ist die Art, in der die Pro- 
grammausführung abgebro- 
chen werden kann. Üblicher- 
weise wird während der I/O- 
Opetationen eine bestimmte 
Funktion aufgerufen, die sich 
um die Móglichkeit des Ab- 
bruchs kümmert. Unter Aztec 
ist dies Chk-Abort(). Sie liefert 
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den Wert null zurück, wenn kein 
Abbruch verlangt wurde. Ist 
CTRL-C gedrückt worden, wird 
der Inhalt der Variablen En- 
able. Abort geprüft: Ist er null, 
so wird die Móglichkeit des Ab- 
bruchs unterbunden, und Chk. 
Abort() liefert einen Wert un- 
gleich null zurück. Der Default 
für Enable Abort ist jedoch 
ein Wert ungleich null, der im 
Fallé von CTRL-C einen soforti- 
gen Ausstieg durch die System- 
funktion __abort() bewirkt, es 
erfolgt also keine Rückkehr aus 
Chk_Abort(). Will ein Aztec-C- 
Programmierer die Abbruch- 
móglichkeit (temporár) unter- 
binden, so setzt er entweder 
Enable. Abort auf null oder er- 
setzt die Funktion Chk__Abort() 
durch eine eigene. 

Lattice-C verhält sich ähn- 
lich, versteckt jedoch imple- 
mentationsabhängige Details: 
Anstelle der Variablen Enable. . 
Abort kann der Programmierer 
durch die Funktion onbreak() 
eine Funktion festlegen, die im 
Falle eines Abbruchs den Wert 
null zurückgibt. Der Default für 
diese »Break-Trap« ist CKBRK(), 
deren Quelltext sich im Ver- 
zeichnis »source« auf den Latti- 
ce-Disketten befindet. Ist also 
kein Abbruch erwünscht, so 
wird dies unter Lattice durch 
int nobreak(void) [ 
return 0; } 

Ж ees, X 
onbreak (nobreak); 
angezeigt. 

Soll an vom Programmierer 
bestimmten Stellen eines Pro- 
gramms zusätzlich auf Ab- 
bruch geprüft werden (etwa in 
l/O-losen Phasen), so kann die 
funktion chkabort() (oder auch 
Chk_Abort()) explizit aufgeru- 
fen werden. 

Entgegen der Erwartung ist 
die vom Compiler verwendete 
int-GróBe selten Ursache von 
Portierungsproblemen, auch 
wenn in Lattices Default-Modus 
ints 32 Bits breit sind. Ausge- 
nommen sind hierbei 16-Bit-Az- 
tec-Programme, deren Funktio- 
nieren von der geringeren int- 
Breite abhängt. Beispiele sind 
hier hartcodierte ObjektgróBen 
(ohne die Verwendung der »si- 
zeof()«-Funktion) oder wenn der 
»Überlauf« einer int-Variablen 
(oder der Verlust der oberen 
Stellen bei der Zuweisung) vor- 
ausgesetzt wird. Diese Fálle 
sind unüblich und mehr von 
theoretischer Natur, nicht zu- 
letzt, weil viele Aztec-Program- 
mierer aus Sicherheitsgründen 
mit der Option +1 (für 32-Bit- 
Integers) übersetzen und sich 
So schwer zu entdeckende 
Bugs ersparen, etwa bei der Pa- 


rameterübergabe oder bei der 
Differenz zweier Zeiger, die bei 
Aztek-C als int - auch bei 16-Вй- 
ints - angesehen wird. 

Lediglich wenige Bibliotheks- 
funktionen stellen den Portierer 
vor Probleme: So wird unter Az- 
tek-C gelegentlich eine Funk- 
tion namens Imalloc() verwen- 
det, die bei Verwendung von 
32-Bit-Integers natürlich durch 
malloc() ersetzt werden kann. 

Besonders unangenehm tritt 
hier jedoch die Funktion rand() 
hervor, da sie unter Aztek-C un- 
abhängig von der Integer- 
Größe (also auch bei сс +l) 
Werte im Bereich von 0 bis 
32767 zurückgibt - im Gegen- 
satz zu Lattice-C, dessen Wer- 
tebereich sich - gemäß ANSI- 
Norm - von 0 bis INT. МАХ 
(siehe <limits.h>) erstreckt. 

Beim Skalieren von Zufalls- 
zahlen gehen Aztek-Program- 
mierer aber meist davon aus, 
daB 32767 der gróBtmógliche 
Ergebniswert ist und erhalten 
so unter Lattice viel zu große Er- 
gebnisse, die möglicherweise 
das Überschreiben unschuldi- 
gen Speichers verursachen 
könnten, etwa bei Verwendung 
als Feldindizes. Folgende Kor- 
rektur löst das Problem: 


#include <math.h> 
#define rand() ((rand) 
() & Ox7fff£) 


Kaum portierbar sind aller- 
dings die Funktionen signal() 
und raise(), die aber ohnehin 
auf beiden Compilern die ANSI- 
Konformitát vermissen lassen. 


Assembler 


Durch die von Aztek-C gebo- 
tene Móglichkeit zum sog. »In- 
line-Code« (siehe folgenden 
Abschnitt) ist es wichtig, die 
Sich auf der Assemblerebene 
ergebenden Unterschiede zu 
kennen. Dazu gehóren in erster 
Linie Assemblersyntax und Ver- 
wendung der Register durch 
den Compiler. Ganz ohne 
Kenntnisse in M68000-Assem- 
bler geht es übrigens nicht. 

Zur genauen Information 
über die Schnittstelle für die 
Kombination von C und Assem- 
bler verweisen wir auf die ent- 
sprechende Literatur (siehe 
Hinweise am Ende dieses Arti- 
kels). In Kürze: Wird von einem 
C-Programm eine Funktion (C 
oder Assembler) aufgerufen, so 
werden zunächst die Parameter 
in umgekehrter Reihenfolge auf 
dem Stapel abgelegt und an- 
SchlieBend ein _Unterpro- 
grammsprung zur gewünsch- 
ten Funktion durchgeführt. Glo- 
bale Symbole - wie sie Funk- 
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tionsnamen darstellen - müs- 

sen bei der Verwendung in As- 

sembler mit einem führenden 

Unterstrich versehen werden. 

Hierzu ein Beispiel: 

-sqr move.l 4(вр),40 
mulu 40,40 
rts 

Zuerst wird der Parameter 


dieser Funktion (die von C aus 
mit dem Namen sort zur Verfü- 


gung steht) vom Stapel gele-. 


sen. Er befindet sich 4 Byte 
über der aktuellen Position des 
Stapelzeigers, da sich darunter 
noch die Rücksprungadresse 
(durch den Unterprogrammauf- 
ruf dort abgelegt) befindet. Da 
Lattice-C im Default mit 32-Bit- 
Integers arbeitet, muß auch ein 
Langwort (.L) geladen werden. 
Dieser Wert wird anschließend 
quadriert, und es erfolgt der 
Rücksprung zur aufrufenden 
Routine. Das Ergebnis muß 
sich bei Rückkehr in DO befin- 
den, was hier auch ohne expli- 
zite MOVE-Anweisung bereits 
der Fall ist. Wird ein 16-Bit- 
Integer-Aztek-C-Programm un- 
ter Lattice im Default-Modus 
übersetzt, so muß außerdem 
unbedingt darauf geachtet wer- 
den, daß das höherwertige 
Wort des Resultats einer As- 
semblerfunktion auch wirklich 
gelöscht ist oder daß die Funk- 
tion explizit als short deklariert 
wird. 

Unterschiede ergeben sich 
auch bei den freien Prozessor- 
registern: So müssen unter Az- 
tek-C die Rgister D4 bis D7 so- 
wie A2 bis A5 gerettet werden, 
unter Lattice-C jedoch - ent- 
sprechend dem Amiga-Stan- 
dard - zusätzlich die Inhalte von 
D2, D3 und А6, da diese vom 
Compiler für die Speicherung 
von Registervariablen und tem- 
porären Ergebnissen verwen- 
det werden. 

Die größten Unterschiede be- 
stehen jedoch in den Steuer- 
anweisungen der beiden As- 
sembler, insbesondere beim 
Symbolim- und -export. 

So ist unter Lattice-C der OR- 
Operator nur in Form des Aus- 
rufezeichens (nicht durch den 
vertikalen Strich à la C), EXOR- 
und Modulo-Operator jedoch 
gar nicht implementiert. 

Ebenfalls nicht vorhanden 
sind die Anweisungen EQUR, 
REG und FREG, die der Defini- 
tion von Registernamen die- 
nen. Im Falle der Verwendung 
in einem Aztec-Assemblerpro- 
gramm müssen diese Synony- 
me direkt durch ihre Register 
ersetzt werden. 

Eine BLANKS-Anweisung 
wird von Lattice nicht unter- 
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stützt, das Operatorfeld darf 
keine Leerzeichen enthalten. 
Die Familie der LIST-Anweisun- 
gen sind unter Lattices ASM 
durch die Option -I implemen- 
tiert, beeinflussen die Codeer- 
zeugung aber ohnehin nicht 
und kónnen daher entfallen. 
Ebenfalls als Kommandozeilen- 
option (-m) steht Azteks MACHI- 
NE-Anweisung zur Verfügung, 
Zeilen mit dem Pseudo-Op- 
code MC68881 können eben- 
falls entfallen. Für den Such- 
pfad der INCLUDE-Anweisung 
existiert keine Environment-Va- 
riable, er muß explizit als Kom- 
mandozeilenoption angegeben 
werden, etwa durch 


ASM -iLC:/Assembler_ 
Headers/ programmname 


Unter früheren Versionen 
des Aztec-Assemblers wurden 
Makroparameter durch »%1« 
bis »%9« spezifiziert. Dies muß 
durch /1 bis /9 ersetzt werden. 

Die Anweisung DCB dient 
dazu, einen Speicherblock zu 
reservieren und mit einem kon- 
stanten Wert zu füllen, etwa in 
der Form 


dc.b BUFFERSIZE,-1 


Dies reserviert einen aus 
BUFFERSIZE Langwörtern be- 
stehenden Speicherbereich 
und füllt jedes Langwort mit 
dem Wert -1. Unter Lattice-ASM 
können nur mit null gefüllte 
Speicherbereiche durch DS 
(»define Storage«) reserviert 
werden. Andere Fälle der DCB- 
Anweisung müssen entweder 
durch Assemblercode initiali- 
siert oder durch DC explizit auf- 
geführt werden. Der Befehl 
EVEN (zur Ausrichtung auf eine 
Wortadresse) entspricht unter 
Lattice »CNOP 0,2« oder »DS.W 
0«. 

Die Anweisung PUBLIC 
dient unter Aztecs AS sowohl 
dem Import als auch dem Ex- 
port von Symbolen. So muß 


public _function 
durch 
xdef —funetion 


ersetzt werden, wenn im glei- 
chen Assemblermodul eine De- 
finition dieses Symbols erfolgt, 
etwa durch eine Zuweisung 
oder Verwendung als Sprung- 
marke. Andernfalls entspricht 
sie 
xref —funetion 

Auch kann unter AS durch ei- 
ne pure Referenz - unabhángig 
davon, ob sie benótigt wird oder 
nicht - bewirkt werden, daB ein 
Teil einer Bibliothek eingebun- 
den wird. Dies wird beispiels- 
weise durch die Anweisung 
»PUBLIC .begin« erledigt. Latti- 


ces ASM behált nur solche Re- 
ferenzen im Objektmodul, die 
auch wirklich verwendet wer- 
den. 

Die GLOBAL-Anweisung 
dient dazu, globalen Speicher 
zu reservieren und áhnelt DS. 


ıglobal _var,8 
wird daher durch 


ds.b 8 
xdef -var 


ersetzt und kann, wie viele an- 
dere hier genannte Anpassun- 
gen, auch durch ein Makro im- 
plementiert werden. Probleme 
entstehen nur dann, wenn ein 
bestimmtes Symbol in mehre- 
ren Modulen auf diese Weise 
definiert wurde. Der Aztec-Lin- 
ker verwendet die maximale 
GróBenangabe und betrachtet 
alle anderen als Deklarationen. 


-var 


Ein solches Feature existiert bei 


Lattice-C nicht, so daß, wenn 
BLink sich über mehrfach defi- 
nierte Symbole beschwert, ma- 
nuell die größte Definition aus- 
findig gemacht, auf die oben 
genannte Weise ersetzt und al- 
le anderen Stellen zu 


xref -var 


geändert werden müssen. Die 
BSS-Anweisung reserviert nur 
lokalen Speicher und kann 
durch DS ohne XDEF ersetzt 
werden. 

Beide Assembler unterstüt- 
zen die Speichermodelle und 
Segmentierung der C-Compi- 
ler, jedoch auf unterschiedliche 
Weise: Aztec hält hierfür die 


Anweisungen 

near code 
near data 
far code 
far data 


bereit und legt Code- und Da- 
tenbereich durch die Anweisun- 
gen CSEG und DSEG fest. Un- 
ter Lattice wird dies kombiniert 
durch die CSECT-Direktive er- 
ledigt. Da für die Funktionsfä- 
higkeit eines Programms die 
absolute Adressierung aus- 
reicht, können NEAR und FAR 
entfallen sowie CSEG durch 
SECTION CODE und DSEG 
durch SECTION DATA ersetzt 
werden. Die SECTION-Anwei- 
sung sollte zu Beginn des 
Quelltextes - im Unterschied zu 
Metacomcos Makroassembler 
- stehen, da ansonsten Fehler- 
meldungen auftreten kónnen. 
Eine selten verwendete Fá- 
higkeit des Aztec-Linkers ist 
aufwendiger umzusetzen: die 
Anweisung ENTRY. Diesem 
Schlüsselwort folgt der Name 
eines globalen Symbols, das 
vom Linker als Eintrittspunkt für 


das entstehende Lademodul 


'verwendet werden soll. Für die 


Anpassung an Lattice wird das 
diesem Symbol folgende Code- 
segment an den Beginn des 
Quelltextes verschoben und 
das entstandene Modul beim 
Binden als erstes Objektmodul 
spezifiziert. Fortgeschrittene 
können ENTRY auch durch 
den SECTION-Namen »NTRY- 
HUNK« implementieren. 


Inline-Code 


Der Aztec-C-Compiler kennt 
eine besondere Anweisung, die 
es erlaubt, Assembleranwei- 
sungen direkt in den Quelltext 
eines C-Programms einzu- 
streuen, eine sehr praktische, 
aber möglicherweise auch sehr 
gefährliche oder gar unnötige 
Sache. 

Hier müssen wir zwei bis drei 
Fälle unterscheiden: 

1.) »echter« Inline-Code 

2.a) separate Assemblerfunk- 
tionen 

2.c) Assemblerfunktionen mit 
C-Kopf. 

Der erste Fall kann uns vor 
Probleme stellen, die als 
»schwierig« bis »nicht portier- 
bar« eingestuft werden können. 
Lassen Sie uns daher zur Ein- 
gewöhnung zunächst einen 
Blick auf die beiden letzteren 
werfen: 2a ist daran erkennbar, 
daß die »#asm«-Anweisung 
außerhalb einer C-Funktion 
verwendet wird. Der Program- 
mierer hat sich also: lediglich 
die Aufteilung seines Quelltex- 
tes in ein C- und ein Assembler- 
Modul gespart. In diesem Fall 
muß der Bereich zwischen 
#asm und #endasm in eine 
separate Datei kopiert und (in- 
klusive der beiden begrenzen- 
den Anweisungen) aus dem C- 
Quelltext entfernt werden. Der 
C-Quelltext muß nun um Import- 
anweisungen für die im Assem- 
blermodul definierten Symbole 
ergänzt werden, entsprechend 
etwaige im Assemblermodul 
definierte globale C-Symbole. 
Des weiteren müssen die glo- 
balen Symbole des Assembler- 
moduls exportiert werden, hier- 
zu ein Beispiel: 


int globvar: 

#asm 

_bzero поуеа.1 4(вр),а0 
поуе 8(вр),40 
bra.s 2$ 

1$ elr.b (a0)+ 

2$ dbf 40,1% 
rts 

#endasm 


void efunc() 
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( 


И ЖОГЫ; ГЛ 
bzero (a, BUFSIZ); 
Е ex x/ 


Dies wird nun zu einem As- 
semblermodul: 


section code 


xdef _bzero 
_bzero поуеа.1 4(вр),а0 
поуе.1 8(sp) ‚do 
;.L hinzugefügt! 
bra.s 2% 
1$- oirbb (a0)+ 
2$  dbf 30,1$ 
rts 
end 


und zu einem C-Modul: 
int globar; 


extern void bzero 
(char ж, int); 
void efunc() 
( р 
/ж... A 
bzero(a, BUFSIZ); 
VE T i 
| 
Griffe die Assemblerfunktion 
auf die Variable globvar zu, so 
müßte dies durch die Anwei- 
sung 


xref —globvar 


angezeigt werden. 

Beachten Sie übrigens auch 
die (bereits besprochene) An- 
derung von MOVE in MOVE.L. 
Im Fall, daß einem 16-Bit-Para- 
meter weitere folgen, ándern 
Sich natürlich die Parameter- 
Offsets (relativ zu Stapelzei- 
ger). д 

Eine ebenfalls noch leicht 
pointbare Variable des vorheri- 
gen Falls lieg vor, wenn nur der 
Funktionskopf in C definiert 
wurde, die eigentliche Funktion 
jedoch in Assembler. Auch hier 
ein Beispiel: 
viod bzero(dest, bytes) 
char xdest 


int bytes 
{ 

#asm { 
movea.l 8(a5),a0 
move 12(а5),40 
bra.s 2$ 

1$ elr.b (a0)+ 

2$ dbf d0,1$ 

# endasm 


Hier wird vom C-Compiler 
der Funktionsein- und-ausgang 
erzeugt, der bei der Portierung 
nach Lattice explizit angege- 
ben werden muß: 

section code g 
xdef —bzero 
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_bzero link аб, #0 
;hinzugefügt 
поуеа.1 8(a5), 
a0 
move.1 12(a5) 
,d0 
;.L, wie gehabt 
bra.s 2$ 
1$ elr.b (a0)4 
2$ dfb 40,1% 
unlk a5 
;hinzugefügt 
rts 
;hinzugefügt 
end 


Durch diese vom Aztec-Com- 
piler erzeugten Anweisungen 
wird erreicht, daß die Parameter 
ab 8 (A5) adressiert werden 
können. А5 wird daher auch als 
»Frame-Pointer« bezeichnet. 
Auch hier müssen 16-Bit-Para- 
meter durch Hinzufügen von .L 
erweitert werden, entsprechen- 
des gilt für die Anpassung der 
Offsets. 

Wirklich schwierig wird es mit 
der #asm-Anweisung erst, 
wenn Assemblercode (schein- 
bar) wahllos in C-Funktionen 
eingestreut wurde. Zwar gibt es 
unter Lattice-C die funktionell 
identische Prozedur . emit(), 
mit deren Hilfe Assembleran- 
weisungen eingefügt werden 
können, hierzu müssen jedoch 
vorher die den Assembleran- 
weisungen entsprechenden 
Zahlenwerte bestimmt werden, 
etwa mit Hilfe des Assemblers. 
Glücklicherweise wird solcher 
»echter« Inline-Code nur selten 
verwendet und kann in den mei- 

*sten Fállen bei Verwendung der 
absoluten Datenadressierung 
entfallen, da er lediglich dem 
Laden des Basisregisters A4 
dient. Das Retten von Registern 
durch #asm, etwa beim Eintritt 
in eine Interrupt-Funktion, kann 
bei Lattice-C unterbleiben, da 
hier die Register entsprechend 
dem Amiga-Standard verwen- 
det werden. 

Ähnlich dem  Inline-Code 
zum Setzen und Retten von Re- 
gistern in Interrupt-Funktionen 
kónnen auch die unter Lattice- 
C nicht vorhandenen - weil 
nicht benótigten - Funktionen 
int start und int end() er- 
satzlos gestrichen werden. Bei 
der Erzeugung neuer Prozesse 
und Tasks, etwa durch Create- 
Task() oder CreateProc() muß 
unter Aztec-C die als Parameter 
übergebene Eintrittsfunktion zu 
Beginn mit der Anweisung 
geta4() versehen werden. Diese 
Anweisung wird von Lattice-C 
verstanden, kann aber bei Ver- 
wendung der Compileroption 
-b0 wegfallen. Wird das Small- 
Data-Model verwendet, so be- 
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wirkt die Option -y, daß beim 
Eintritt in jede Funktion auto- 
matisch das Basisregister A4 
geladen wird. 

Eine weitere Spezialität stellt 
das Binden ohne Startup-Code 
dar. Hier wird bei Aztec mit der 
Option +b compiliert, unter Lat- 
tice muB der Linker separat vom 
Compiler, ohne Angabe des 
sonst üblichen Startup-Codes 
LIB:c.o aufgerufen werden. 

Die Überprüfung auf Stapel- 
überlauf wird von Lattice per 
Default durchgeführt und muB 
explizit durch Option -v abge- 
schaltet werden, während +m 
sie unter Aztec-C erst einschal- 
tet. Sollte ein Aztec-Programm 
die Symbole . stkchk() und 
— —Stkover() verwenden, so weist 
dies darauf hin, daB der Pro- 
grammierer eine eigene Über- 
prüfung des Stapelüberlaufs 
vornimmt. Diese ist nicht direkt 
portierbar, sollte jedoch auch 
keinen direkten Einfluß auf die 
Programmausführung haben, 

Sogenannte »Load-and-Stay- 
Resident«-Programme (oder, in 
Anlehnung an MS-DOS, auch 
TSRs) sind kompatibel imple- 
mentiert, es muß bei Lattice le- 
diglich mit dem Startup-Code 
LIB:cback.o gelinkt werden. Bei 
Aztec-C ist detach.o für die »Ab- 
nabelung« verantwortlich. 

Zwei Tricks, die von Aztec- 
Programmierern gerne zur Op- 
timierung der Programmlänge 
angewandt werden, bestehen 
in der Reduzierung des aus der 
Kommandozeilenanalyse re- 
sultierenden Overheads. Hier- 
zu wird die Eintrittsfunktion 
nicht maint), sondern __main() 
genannt. Diese erhált zwei Pa- 
rameter: als ersten Parameter 
die Anzahl der gültigen Zeichen 
der Kommandozeile und als 
zweiten einen Zeiger auf die 
Kommandozeile selbst. Auch 
unter Latice-C existiert eine sol- 
che Funktion - maint, sie er- 
hált jedoch lediglich einen Zei- 
ger auf einen mit einem Nullby- 
te beendeten String. Dieser Un- 
terschied sollte auch C-Einstei- 
ger vor kein Problem stellen. 
Stub-Definitionen der internen 
Funktionen .. cli parse() und 
— wb. parse(), die für die Aus- 
wertung von Parametern zu- 
stándig sind, kónnen entfallen, 
haben jedoch keinen Seitenef- 
fekt auf die Funktionsfáhigkeit 
eines Programms. 


Wenns dann 
nicht läuft... 
Verabschiedet sich das auf 


die beschriebene Weise adap- 
tierte Programm bei Ausfüh- 


rung noch immer durch einen 
Guru oder ähnliches, so bleibt 
wohl nur noch der Source-Le- 
vel-Debugger. Dort verfolgen 
Sie die Programmausführung 
bis zur Crash-Position (mit Tra- 
ce geht es Funktionen hinein) 
und untersuchen den Objektco- 
de des zugehörigen Pro- 
grammsegments durch CPR im 
Mixed-Modus oder durch OMD. 

Auch das Startup-Modul 
catch.o leistet bei solch schwie- 
rigen Fällen hilfreiche Dienste, 
da es Abstürze abfangen kann 
und dabei die Stelle und den 
Umstand des Absturzes näher 
eingrenzen hilft. 

Auf diese »allgemeine« Wei- 
se übertragene Programme 
sind natürlich noch nicht opti- 
miert und benötigen gewisse 
Verfeinerungen, um alle Eigen- 
schaften des Lattice-Compilers 
nutzen zu können. Dazu gehö- 
ren dann beispielsweise die Pa- 
rameterübergabe in Registern 
und der geschickte Einsatz der 
Speichermodule. Auch der 
»Globale Optimizer« kann in ei- 
nigen Fällen, speziell beim Um- 
gang mit l/O-Registern, erst 
eingesetzt werden, wenn das 
Schlüsselwort volatile richtig 
angewandt wird, da ansonsten 
- im Unterschied zu Aztec-C - 
Optimierungen vorgenommen 
werden, die über den Rahmen 
des Erwünschten hinausge- 
hen. Die Umsetzung auf 16-Bit- 
Integer (Lattice-Option -w) ist 
unter Lattice durch die Unter- 
stützung von ANSI-Prototypes 
zwar wesentlich einfacher, 
bringt aber nur selten mehr als 
rund 1 Prozent der Programm- 
länge. 

, Viele der hier genannten Tips 
können übrigens auch von 
Aztec-Programmierern berück- 
Sichtigt werden, ohne daß diese 
deshalb irgendwelche  Lei- 
stungseinbußen hinnehmen 
müssen. Die Anwendung der 
Práprozessorsymbole AZTEC. . 
C und LATTICE C tun ein 
übriges zur leichten Portierung. 


So 


»Using C will definitely cut your life expectency 
byten years or more« - Carl Sassenfath, Gurus 
Guide #1, Seite 45. 

Literaturhinweise 
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Mathematische Spieltheorie 


piel mit 


Zahle 


Warum habe ich gegen 
meinen Schachcomputer 


keine Chance? 


Hier erfahren Sie 


mehr über die 


mathematischen 


Hintergründe. 


Von Jürgen Singer 


omputer gelten als flei- 
Big, aber dumm. Wie 
sollen diese »geistlo- 


sen« Maschinen je die Spiel- 
stárke eines kreativ denkenden 
menschlichen Gegners errei- 
chen? Natürlich werden Sie 
einwenden, auch Fleiß hat sei- 
ne guten Seiten. Die Maschine 
kónnte ja alle denkbaren Móg- 
lichkeiten durchkalkulieren und 
sich dann für die beste ent- 


scheiden - eine Möglichkeit, 
die der Mensch bei aller Kreati- 
vität nicht hat. 

Doch wie groß wäre der Re- 
chenaufwand für diese Sysi- 
phusleistung? Je nach Situa- 
tion haben Sie für den nächsten 
Zug die Wahl unter etwa sech- 
zig Möglichkeiten. Zu beden- 
ken gilt es jedoch nicht nur den 
nächsten Zug, sondern auch 
die mögliche Reaktion des 
Gegners (nochmals etwa sech- 
zig Züge pro eigener Zugmög- 
lichkeit) und alle weiteren Züge 


(einschließlich Reaktionen des 
Gegners) bis zum zwangsläufi- 
gen Matt. Gehen wir davon aus, 
daß eine Partie im Schnitt etwa 
60 Züge dauert, so ist dies ein 
Rechenaufwand von 60 hoch 
120 Varianten, die kalkuliert 
sein wollen, bevor die nächste 
Figur gesetzt wird - alles in al- 
lem eine Zahl mit enorm vielen 
Nullen. Zur Berechnung des er- 
sten Zuges veranschlagen wir 
am besten einen Aufwand von 
einigen Jahren - immer voraus- 
gesetzt, wir haben einen Super- 


computer vom Format einer 
Cray zur Verfügung, den wir mit 
unseren Daten füttern können. 

Sie haben keine Cray? Und 
auch keine Zeit, um solange zu 
warten? Dann sollten Sie sich 
einen effektiveren Algorithmus 
einfallen lassen. Denn es ist si- 
cher nicht sinnvoll, jedesmal al- 
le Züge zu kalkulieren, bevor 
Sie einen Spielstein setzen. Be- 
vor wir uns mit unseren Überle- 
gungen an das - relativ kompli- 
ziert - Schachspiel wagen, 
lassen Sie uns mit einem einfa- 


chen Beispiel beginnen: Es gibt 


zwei Spieler, die wir »Links« und 
»Rechts« nennen wollen. Zu- 
dem gibt es »Bauklötzchen«, 
die die Aufdrucke »L« und »R« 
tragen. Ein Spielzug von 
»Links« bedeutet, einen Klotz 
mit dem Aufdruck »L« zu entfer- 
nen, analog darf »Rechts« bei 
jedem Zug einen »R«-Klotz ent- 
fernen. Die Klötze sind überein- 
ander gestapelt, so daß beim 
Entfernen eines Klotzes auch 
alle weiteren Klötze, die dann 
nicht mehr mit der Erde ver- 


bunden sind, entfernt werden. 
Als Verlierer gilt der Spieler, der 
zuerst nicht mehr ziehen kann. 
Selbstverständlich würden Sie 
es vorziehen, der Gewinner zu 
sein, doch wie stellt man das 
an? 

Zum Aufwärmen betrachten 
wir die Situation in Bild 1: Hier 
liegen zwei getrennte Haufen 
vor. Es entscheidet allein die 
Anzahl der vorhandenen Stei- 
ne, sofern niemand auf die Idee 
verfällt, einen Stein zu entfer- 


nen, der noch weitere Steine №» 


Bild 1. 
Die 


Steine 
ent- 


über 
den 


ner 


trägt. Da »Links« über 6 Steine 4a dargestellt: 


Anzahl 


scheidet 


Gewin- 


Beginnt 


- ein Nullspiel, bei dem »Links« 
beginnt. Ist nun andererseits 
»Rechts« als erster am Zug, so 
kann er wieder einen Stein von 
einem zu »Links« gehörenden 
Stapel herunternehmen. Die 
beste Chance für »Links« be- 
steht darin, »Rechts« einen Zug 
zu stehlen, daher wird »Links« 
den verbleibenden Turm neh- 


von 7,5. Stellen wir uns die Fra- 
ge, welche Züge hier möglich 
sind, so ergibt sich für »Rechts« 
nur ein möglicher Zug, der zur 
Position 7+1 = 8 für »Links« 
führt. »Links« kann dagegen 
entweder einen Klotz aus sei- 
nem privaten Stapel nehmen, 
was 6,5 ergeben würde, oder 
besser er nimmt den 1/2-Stapel, 


Bild 3. 
Änderungen 
durch 
Mischen? 


verfügt, während »Rechts« de- 
ren 7 hat, gewinnt »Rechts« auf 
jeden Fall (sofern er keine un- 
vernünftigen Züge macht), un- 
abhängig davon, ob »Links« 
oder »Rechts« das Spiel be- 
ginnt. 

Wie sieht die Situation nun in 
Bild 2 aus? Jeder Spieler ver- 


»Rechts«, so kann er nur den 
oberen Klotz nehmen; im näch- 
sten Zug nimmt »Links« den un- 
teren Klotz und gewinnt damit. 
Beginnt dagegen »Links«, so 
nimmt er sofort den unteren 
Klotz und entfernt damit auch 
den oberen Klotz. Damit kann 
»Rechts« nicht mehr ziehen 


Bild 2. 


men und wir enden wieder bei 


Bei 


zieht 


gleicher 
Anzahl 
gewinnt, 
wer als 
zweiter 


der Situation 4d. Da nun aber 
»Rechts« am Zug ist, gewinnt 
»Links«. Also handelt es sich 
bei Bild 4c tatsächlich um ein 
Nullspiel und unsere Hypothe- 
se, daß Bild 4a einen Vorsprung 
von einem halben Zug für 
»Links« bedeutet, hat sich be- 
stätigt. Werfen wir einen Blick 
auf Bild 5. Wie sofort ersichtlich 
ist, hat diese Figur einen Wert 


was zu 7 führt. Diese Optionen 
wollen wir in Zukunft durch die 
Gleichung |718 |-7.5 aus- 
drücken. Allgemeiner gilt also 
п1п+1 |- n + 1/2. Es gibt 
auch noch die einfachere Glei- 
chung {nI}=n+1; denn hat 
»Links« n+1 freie Züge, so hat 
er nach seinem Zug natürlich 
noch n freie Züge, »Rechts« 
kann dagegen überhaupt nicht 
ziehen. 


fügt über die gleiche Anzahl 
von Klötzen. Bei optimalen Zü- 
gen (das heißt jeder Spieler 
nimmt immer nur jeweils einen 
Stein) kann derjenige zuerst 
nicht mehr ziehen, der das 
Spiel begonnen hat. Ein Spiel 


bei dem der, der anfängt, 
zwangsläufig verliert, soll »Null- 
spiel« heißen. 

Bild 3 unterscheidet sich von 
Bild 2 dadurch, daß einige Klöt- 
ze zwischen den beiden Sta- 
peln ausgetauscht wurden. Wie 
ist die Situation jetzt? Aus Sym- 
metriegründen kann man na- 
türlich vermuten, daß auch hier 
keiner der Spieler einen echten 
Vorteil haben wird, doch stimmt 
das? Sicherlich, denn was auch 
immer ein Spieler unternimmt, 
sein Gegner kann mit genau 
demselben Zug am anderen 
Stapel kontern. Somit verliert 
auch hier derjenige, der das 
Spiel beginnt und wir haben 
wieder ein klassisches Null- 
spiel. Die Hauptschwierigkeit 
bei diesem Spiel ist, daß es un- 
ser Gegner einrichten kann, 
uns einige Züge zu stehlen, in- 
dem er Klötze entfernt, die Klöt- 
ze von uns tragen. Die einfach- 
ste derartige Situation ist in Bild 
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und »Links« gewinnt wieder. Be- 
trägt der Vorteil von »Links« ge- 
nau einen Zug? Wir können die- 
se Hypothese testen, indem wir 
»Rechts« einen Zug mehr ver- 
schaffen (Bild 4b). Dann aber 
kann »Rechts« gewinnen, un- 
abhängig davon, wer beginnt. 
Also war das Hinzufügen eines 
ganzen Zuges zuviel des Gu- 


Was sind 
halbe Züge? 


ten - der Vorteil von »Links« 
wurde überkompensiert. Daher 
ist der Vorteil von »Links« klei- 
ner als die Vorgabe eines frei- 
en, ganzen Zuges. Stellen wir 
also die Hypothese auf, daß der 
Vorteil von »Links« einen halben 
Zug beträgt. Wenn wir mit unse- 
rer Vermutung recht haben, 
dann muß Bild 4c ein Nullspiel 
darstellen, denn der Vorteil von 
zwei halben Zügen für »Links« 
sollte den freien Zug von 
»Rechts« gerade aufheben. 
Lassen wir also »Links« begin- 
nen. Es kann nur einer der bei- 
den Zweierstapel entfernt wer- 
den. »Rechts« kann nun seinen 
Klotz vom zu »Links« gehören- 
den Klotz entfernen und wir er- 
halten die Situation von Bild 4d 


Was ist ein Spiel? 


Um den Begriff »Spiel« exakt fassen zu können, muß dieser zu- 
nächst definiert sein. Wir einigen uns für diesen Artikel auf folgende 
Definition: 

1. Es gibt genau zwei Spieler, hier als »Links« und »Rechts« bezeich- 
net. 

2. Es gibt verschiedene (endlich viele) Positionen, häufig gibt es eine 
definierte Startposition. 

3. Esgibt feste Spielregeln, die von einer Position aus bestimmte Züge 
erlauben, welche zu neuen Positionen führen. Diese neuen Positio- 
nen sind die »Optionen« der aktuellen Position. 

4. »Links« und »Rechts« ziehen während des ganzen Spiels abwech- 
selnd. 

5. Derjenige Spieler, der nicht mehr ziehen kann, hat verloren. 

6. Das Spiel ist nach einer endlichen Zahl von Zügen beendet. Es gibt 
keine Schleifen, bei denen eine bestimmte Position immer wieder auf- 
tritt. 

7. Beide Spieler verfügen über die vollständige Information über ihre 
Optionen und die ihres Gegners. 

8. Es gibt keine Zufallszüge (Würfeln oder Ziehen von Karten). 
Beispiele: 

- Schach und Dame: verstoßen gegen Punkte 5 und 6. 

- Backgammon: verstößt gegen Punkt 8. 

- Schiffeversenken: verstößt gegen Punkt 7, denn die Position des 
Gegners ist unbekannt. 

- Pflock-Solitaire: ist ein Ein-Personen-Spiel, verstößt damit gegen 
Punkt 1. 

- Міт: erfüllt alle Bedingungen und zusätzlich eine weitere: Jeder 
Spieler kann von jeder Position aus die gleichen Züge machen. Ein 
derartiges Spiel heißt neutral. 

Daß einige Spiele gegen die hier genannten Bedingungen versto- 
Ben, bedeutet nicht, daß Sie nicht mit denselben Algorithmen erfaßt 
werden können. Sie werden nur der Einfachheit halber aus der Be- 
trachtung ausgeschlossen. 
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Die einfachste Gleichung ist 
zweifellos (1) = 0, denn da nie- 
mand ziehen kann, verliert au- 
tomatisch derjenige, der das 
Spiel beginnt und wir haben ein 
Nullspiel vorliegen. 

Betrachten wir nun ein neues 
Spiel: Es wird auf einem n+m- 
Schachbrett gespielt. Jeder 
Spieler besitzt Steine, die sein 
Symbol-(L oder R) tragen. Der 
Spieler »Links« darf mit seinen 
Figuren nur nach Osten ziehen, 
während »Rechts« nur nach 
Westen ziehen darf. Die Zug- 
weite bleibt jedem Spieler frei- 
gestellt, er muß jedoch minde- 
stens ein Feld weit ziehen. Ein- 
zige Ausnahme ist der Fall, 
wenn er genau über einer geg- 
nerischen Figur steht und unter 
dieser ein freies Feld ist: Hier 


darf er auswählen, ob er nicht, 
statt einen normalen Zug zu 
machen, die gegnerische Figur 
überspringen möchte, wobei ei- 
ne schon einmal übersprunge- 
ne Figur selbst keine anderen 


Figuren mehr überspringen 
darf. Bild 6 zeigt als Beispiel ein 
4 x 6-Springer-Spiel. Solange 
sich die Figuren nicht über- 
springen können, ist der Fall 
klar: Es handelt sich dann um 
unser Bauklötzchen-Spiel in 
verkappter Form. 

Doch welche Vorteile bringt 
ein Sprung? Betrachten wir da- 
zu Bild 7: Ist »Rechts« am Zug, 
so bietet sich keine Sprung- 
möglichkeit, und »Rechts« zieht 
ein Feld nach Westen, wobei 
ein Nullspiel entsteht. Ist dage- 
gen »Links« am Zug, so kann er 
entweder nach Osten ziehen, 
was einen Vorsprung von zwei 
Zügen für »Rechts« ergibt; bes- 
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Bild 4. 
Vorteil 
durch 
halbe 
Züge? 


ser für »Links« ist deshalb ein 
Sprung, der den Vorsprung von 
»Rechts« auf 1 schrumpfen läßt. 
Also ist die Bewertung der Si- 
tuation in Bild 7 (-1 1 0 | = -1/2. 
Ganz analog läßt sich bei Sprin- 
ger jede Situation dann einfach 
durch Auszáhlen der Felder óst- 
lich der »Linken« Figuren und 
abziehen der Felder westlich 
der »Rechten« Figuren bewer- 
ten, wenn keine Sprünge mehr 
möglich sind. 


Um eine beliebige Aus- 
gangssituation zu bewerten, 
müssen wir erst alle Zugmóg- 
lichkeiten durchspielen, bis wir 
jeweils eine Bild 7 entsprechen- 
de Stellung erreichen. Da wir 


Bild 5. Der 
entschei- 
dende Fort- 
schritt: 

die Bewer- 
tung von 
Spielsitua- 
tionen 


deren Bewertung kennen, kón- 
nen die Ergebnisse dann rück- 
wárts wieder in die vorherge- 
henden Züge eingesetzt wer- 
den, bis schlieBlich auch die 
Ausgangssituation bewertet ist. 
Ein entsprechender Spielbaum 
kann in Bild 8 bewundert wer- 
den. Dabei gilt es aber noch ei- 
ne Schwierigkeit zu lósen: Wie 
berechnet man [0,5 1 35) = 1 
oder |-251-05) = -1? Zum 
besseren Verständnis des Ве- 
rechnungsprinzips dient Bild 9: 
Hier ist ein Zahlenbaum ange- 
geben, der die Zahlengerade 
nach Brüchen von Zweierpo- 
tenzen unterteilt. Die Bewer- 
tung unserer dubiosen Stellun- 
gen erhalten wir als die »ein- 
fachste« Zahl, die tatsächlich 
größer als die »Links«-Option 
und kleiner als die »Rechts«- 
Option ist. Dabei heißt einfache 
Zahl nichts anderes, als mög- 


Know-How 


lichst nahe an der Wurzel (der 
0) des Zahlenbaumes. Einige 
interessante Neuerungen erge- 
ben sich, wenn die »Links«- 
Optionen größer sind als die 
»Rechts«-Optionen, denn dann 
ergeben sich als Bewertung 
keine Zahlen mehr. Aus Platz- 
gründen können wir hier leider 
nicht auf diese Eigenschaften 
eingehen, sie werden jedoch in 
der angegebenen mathemati- 
schen Literatur ausführlich be- 
handelt, so daß Sie Ihrer Neu- 


programm benötigt werden: Ein 
Teil des Programms muß be- 
stimmen, welche Züge möglich 
sind, ein anderer Teil muß die 
nach einer bestimmten Anzahl 
von Zügen entstandene Situa- 


Unscharfe Spiele 


tion bewerten. Was in unserem 
Beispiel fehlt, ist die Möglich- 
keit für einen Spieler, den be- 
sten unter mehreren Zügen 
auszuwählen. Auf diese Pro- 


Bild 6. Neue 
Möglichkeiten 
mit 
»Springer« 


НШІ Zb 
НЕШЕ 
ist i 


Bild 7. 

Auch hier ist von 
Bedeutung, 
welcher 


Spieler am Zug 


gier keinen Zwang antun müs- 
sen. 

Listing 1 zeigt ein C-Pro- 
gramm, das den Spielbaum 
aus Bild 8 (siehe auch Bild 9) 
berechnet. Dabei existiert im 
Speicher kein direktes Abbild 
des Spielbaums, sondern er 
wird durch wiederholte Aufrufe 
der Bewertungsfunktion (Re- 
kursion) implizit erzeugt. Die 
dargestellte Situation ist sehr 
einfach, da jeder Spieler nur ei- 
ne Figur besitzt, und auch die 
Zugmöglichkeiten sind sehr ge- 
ring - in »richtigen« Spielen, wie 
etwa Dame muß hier schon et- 
was mehr Aufwand getrieben 
werden. Trotz dieser Einschrän- 
kungen enthält das Listing fast 
alle Teile, die von einem Spiel- 


Unscharfe Spiele 


grammteile werden wir später 
noch ausführlich zu sprechen 
kommen. Vorerst geben wir uns 
damit zufrieden, Werte wie |-3.5 
| -0.25} berechnen zu können. 

Lassen Sie uns einen Blick 
auf Tabelle 1 werfen: Bis auf die 
mit »unscharf« bezeichnete бі- 
tuation sind uns alle Möglich- 
keiten schon untergekommen. 
Um auch Situationen zu erfas- 
sen, in denen der Spieler ge- 
winnt, der das Spiel beginnt, 
benötigen wir in unserem Klötz- 
chenspiel eine neue Art von 
Spielstein. Dieser ist einfach 
ein Klotz ohne Aufdruck, daher 
kann er von jedem der Spieler 
genommen werden. Betrach- 
ten wir das Spiel in Bild 10a). Da 
der unterste Klotz keinen Auf- 


Links beginnt 


Links gewinnt | Rechts gewinnt 


Links gewinnt 


Null 


positiv 
(2 gewinnt) 


(L gewinnt) 


Rechts 
beginnt 


Rechts 
gewinnt 


unscharf 
(1 gewinnt) 


negativ 
(R gewinnt) 


Tabelle 1. So sieht das bis zum Ende berechnete Spiel aus 
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Bild 8. Der Spielbaum informiert über die möglichen Züge 


druck hat, kann der Spieler, der 
zuerst mit Ziehen dran ist, das 
Spiel gewinnen, indem er ein- 
fach den ganzen Stapel nimmt. 
Trotzdem ist es nicht sinnvoll, 
auch einem unscharfen Spiel 
den Wert 0 zuzuordnen. Ве- 
trachten wir dazu Bild 10b), wel- 
ches aus zwei Versionen von 
Bild 10a) besteht. Dieses Spiel 
ist nun eindeutig positiv: Unab- 
hängig davon wer beginnt, hat 
»Links« genügend freie Züge, 
um dafür zu sorgen, daß 
»Rechts« als erster einen neu- 
tralen Stein nehmen muß - 
»Links« nimmt dann den ande- 
ren neutralen Stein und ge- 
winnt. Wáre der Wert von Bild 
10a 0, so müßte auch der Wert 
von Bild 10b 0 sein, denn die 
Summe zweier Nullspiele ist 
wieder ein Nullspiel. 

Wie viele Züge für »Links« 
müssen wir hinzufügen, um ein 
positives Spiel zu erhalten, wie 


UD. 


viele Züge für »Rechts« für ein 
negatives Spiel? Fügen wir ei- 
nen ganzen Zug für »Links« hin- 
Zu, so ist das Spiel sicher posi- 
tiv, doch wie steht es mit einem 
halben Zug, oder gar einem 
viertel Zug. 

In Bild 10c fügen wir einen 
Ма Zug hinzu (bitte rechnen 
Sie nach - es stimmt tatsách- 
lich), und schon ist das Spiel 
positiv, denn falls »Links« be- 
ginnt, nimmt er den neutralen 
Stein und entfernt damit den 
ganzen Stapel. 

Im anderen Stapel gehört 
»Links« jedoch der unterste 
Stein und er hat auch hier den 
letzten Zug. Dabei ist es voll- 
kommen belanglos, wie viele 
Steine »Rechts« auf dem Stein 
von »Links« liegen hat, solange 
der Wert des Stapels nur gróBer 
als 0 ist. Wir kónnen die Situa- 
tion aber auch umkehren und 
einen negativen Stapel (Bild 
10d) hinzufügen. 
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Bild 9. Eine neue Variante des Zahlenbaums aus Bild 8 
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Jetzt gewinnt in jedem Fall 
»Rechts«. 

Damit haben wir also ge- 
zeigt: Der Wert des Stapels in 
Bild 10a ist kleiner als jede posi- 
tive Zahl, aber größer als jede 
negative Zahl, dennoch ist er 
nicht 0. Eine ähnliche Position 
erhält man bei einem Spiel, das 
als einzigen Spielstein einen 
neutralen Klotz enthält: Wer an- 
fängt gewinnt, denn die Optio- 
nen bei desem Spiel sind für 
beide Spieler ein Nullspiel, also 
ist der Wert unseres Spieles 
(010). Da dieser Wert häufiger 
auftritt, wollen wir ihn mit dem 
Symbol »+« abkürzen. Allge- 
meiner können wir dann auch 
Schreiben {x | x} = x + * = x*, 
ähnlich wie wir ja auch 3% für 
3+ schreiben. Setzen wir 
zwei neutrale Klótze nebenein- 
ander, so erhalten wir natürlich 


wieder ein Nullspiel, also gilt. 


die Gleichung * + * = 0. 


Bild 18c) Links gewinnt 


an = 


Bild 10d) Rechts паа 


0 Steinen zurückbleibt, oder er 
nimmt einen Stein und läßt den 
anderen stehen. Allgemein gilt: 
*n = [*0, +1, ..., *(n-1) | *0, 21, 

, *(n-1)}. Dieses Spiel mit den 
neutralen Klötzchen heißt 
»Nim« und die zugehörigen 
Werte werden als »Nim-Zahlen« 
bezeichnet. Wir sehen sofort, 
daß ein einzelner Nim-Haufen 
unscharf ist, denn der Spieler, 
der beginnt, nimmt einfach den 
ganzen Haufen und gewinnt. 
Ebenso ist uns sofort klar, daß 
ein Spiel aus zwei gleich gro- 
Ben Haufen ein Nullspiel ist, 
denn der zweite Spieler kann 
gewinnen, indem er jeden Zug 
des ersten Spielers nachmacht. 
Als Gleichung ausgedrückt 
heißt dies: «n + *n = 0. Dasich 
zwei gleich große Haufen zu 0 
addieren, kann man sie bei der 
Betrachtung von Spielen mit 
mehreren Haufen auch einfach 
weglassen. 


Bild 10. Ein neutraler Spielstein sorgt für neue Impulse 


Da Spiele mit neutralen Stei- 
nen offensichtlich interessant 
werden kónnen, betrachten wir 
doch einfach Varianten, die nur 
aus neutralen Steinen aufge- 
baut werden. Wie üblich, spie- 
len wir mit mehreren Haufen 
von Klótzen (Bild 11). Führen wir 


Nim und 
Nim-Zahlen 


als Abkürzung für den Wert ei- 
nes Haufens aus n neutralen 
Klötzen das Symbol *п ein. Da- 
mit gelten die folgenden Glei- 
chungen: *0 = (1]2 0,*1 = (* 
01>0) = |010) = >. Für Hau- 
fen, die aus mehreren Klötzen 
bestehen, haben wir mehrere 
mögliche Spielzüge. 

Damit ergibt sich +2 = {+0, 
*11*0, +1} = (0, + 10, +}, den 
der Spieler, der am Zug ist, 
kann entweder beide Steine 
nehmen, wobei ein Haufen aus 


Ähnlich einfach sieht man, 
daß zwei ungleiche Haufen wie- 
der ein unscharfes Spiel erge- 
ben: der erste Spieler macht 
beide Haufen gleich hoch. Da- 
mit ist in einem Spiel mit drei 
Haufen der Spieler der Verlie- 
rer, der entweder zuerst einen 
Haufen ganz entfernt, oder 
aber einen Haufen gleich hoch 
macht wie einen anderen. Aus 
diesen Gründen ist es einem 
Spieler dringend angeraten, im 
Spiel*1 + *2 + *3 nicht anzu- 
fangen - denn wer anfängt, ver- 
liert. Damit ist aber gezeigt: “1 
+ *2 + *3 = 0. Addieren wir zu 
dieser Gleichung auf beiden 
Seiten +1, «2 oder +3, so erhal- 
ten wir wegen *n + *n = 0: +2 
+ *3 = *1,*1 + +3 = #2, #1 
Ж «2 = +3, Aus diesen etwas 
merkwürdigen Gleichungen ist 
ersichtlich, daß sich Nim- 
Zahlen anders addieren alsrea- 
le Zahlen. Da wir hier nicht zu 
weit in die Theorie abschweifen 
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Bild 12. 
Das Northcot- 
Spiel 


wollen, sei nur gesagt, daß die 
Addition von Nim-Zahlen dem 
Bilden der »exklusiven oder«- 
Verknüpfung der zugehörigen 
normalen Zahlen entspricht, al- 
50%6 + «4 = +(6 XOR 4) = +2. 
Mit Hilfe dieser Rechenregeln 
läßt sich bestimmen, wie in Bild 
11 gezogen werden muß, um zu 
gewinnen: der Zug von *3 nach 
*2 liefert *2 + +4 + +6 = 0, da- 
her wird dem Gegner ein Null- 
spiel überlassen und derjenige, 
der jetzt am Zug ist, kann das 
Spiel gewinnen. 


Erweitertes Nim 


Wenden wir uns einem Spiel 
zu, das nach seinem Erfinder 
Northcot benannt ist (Bild 12). 
Es wird auf einem Schachbrett 
gespielt, wobei jeder Spieler 
acht Damesteine besitzt. Jeder 
Spieler darf nur in seiner Reihe 
ziehen, wobei jedoch ein geg- 
nerischer Stein nicht über- 
sprungen werden darf. Auf den 
ersten Blick hat dieses Spiel 
nichts mit Nim zu tun, doch in- 
terpretiert man den Abstand 
zwischen den jeweiligen Stei- 
nen einer Reihe als einen Sta- 
pel von Klótzen, so entspricht 
das aufeinander zu ziehen dem 
Verringern des Stapels. Zum 
Unterschied zum normalen 
Nim kann hier jedoch ein Spie- 
ler auch Klötze zum Stapel hin- 
zufügen, indem er vom Gegner 
weg zieht. Dies braucht uns je- 
doch nicht: weiter zu beunruhi- 
gen, denn jeden Zug, bei dem 
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Bild 11. 
Nim-Spiele 
und 
Nim-Zahlen 


ein Spieler einen Haufen ver- 
größert, kann sein Gegenspie- 
ler im nächsten Zug wieder 


rückgängig machen. Besitzt 
man also für gewöhnliches Nim 
eine Gewinnstrategie, so auch 
für diese erweiterte Version. 

Daß sich Northcots Spiel 
durch Nim beschreiben läßt, ist 
kein Zufall: Es gibt einen mathe- 
matischen Satz, daß jedes neu- 
trale Spiel äquivalent zu erwei- 

stertem Nim ist. Es stellt sich fol- 
gende Frage: Haben wir ein 
neutrales Spiel, bei dem beide 
Spieler die Optionen (ха, «Б, «с, 
Га, *b, *с,...) besitzen, wel- 
cher Nim-Haufen entspricht 
dann diesem Spiel! Um noch 
etwas konkreter zu werden: 
Welche Nim-Zahl gehört zu +x 
= [*0, «1, 24, 29140, «1, #4, 
*9]? Die Nim-Zahl *x láBt sich 
sehr einfach mit Hilfe der soge- 
nannten MEX-Regel bestim- 
men (MEX = minimal excluded 
number, d. h. die kleinste aus- 
geschlossene Zahl). Die klein- 
ste Zahl, die in unserem Bei- 
Spiel nicht vorkommt, ist *2. 
Wie wir schon wissen, hat +2 
die Zahlen «0 und +1 als Optio- 
пеп, die Zahlen «4 und «9 kön- 
пеп wir uns als solche Optionen 
vorstellen, bei denen der Hau- 
fen von 2 auf 4 oder 9 Steine 
vergrößert werden kann. 

Das Spiel Nim (und damit alle 
neutralen Spiele) haben den 
entscheidenden Vorteil, daß sie 
noch einigermaßen leicht bere- 
chenbar sind, für unser erstes 
Spiel, bei dem die Klötzchen 


Know-How 


durch Aufdrucke den jeweiligen 
Spielern zugeordnet waren, gilt 
dies nicht. Wollen wir hierfür ein 
Programm für unseren Compu- 
ter schreiben, so müssen wir 
damit rechnen, daß die Zeit, die 
der Computer zur Berechnung 
der Spielpositionen benötigt, 
exponentiell mit der »Länge« 
der eingegebenen Anfangssi- 
tuation zunimmt. Derartige 
Spiele nennt man »hart«. Weite- 
re harte Spiele sind etwa Dame 
und Schach. Führt man eine 
(sehr konservative) Schätzung 
der benötigten Rechenzeit für 
ein Dame-Spiel durch, so erhält 
man für die schnellsten heute 
verfügbaren Computer Laufzei- 
ten von einigen 10000 Jahren. 
Da es aber Schach- und Dame- 
programme überall zu kaufen 
gibt, heißt dies, daß diese Pro- 
gramme nach anderen Prinzi- 
pien arbeiten müssen. Doch 
auch diese Spielprogramme 
können auf den Spielbaum 
nicht verzichten. Aber es bietet 
sich doch eine erste Verbesse- 
rung an: Im Spielbaum von Bild 
8 ist bei jedem Zug offen, wel- 
cher der beiden Spieler nun tat- 
sächlich zieht - denn von Inter- 
esse war ja die Bewertung der 
Position, unabhängig davon, 
wer gerade am Zug ist. Bei ei- 
nem konkreten Spiel, das auf 
einem Computer implementiert 
werden soll, ist die Situation et- 
was anders: Es ist bekannt, wel- 
cher Spieler am Zug ist - daher 
kann man den Spielbaum um 
etwa die Hälfte reduzieren, 
doch dies alleine hilft nicht sehr 
viel, denn die Hälfte von einigen 
zehntausend Jahren Rechen- 
zeit sind immer noch einige 
fünftausend Jahre. Es führt 
also kein Weg daran vorbei: Es 
ist einfach nicht möglich, den 
kompletten Spielbaum zu be- 
rechnen. Also bleibt nichts an- 
deres übrig, als die Berechnun- 


Ausdrücken: 
10) = -1, (1-1) 
011) = 1/2, (112) = 3/2, 


- Zweierpotenzen: 


- Einfachheitsregel: 


Bewertungen von Spielpositionen 


- (a,b, c, ... 1 d, e, f, ...] ist eine Spielposition, bei der die Optionen von 
»Links« zu den Werten a, b, c, ... führen, während die Optionen von 
»Rechts«zu den Werten d, e, f, ... führen. 

- Die ganzen Zahlen entsprechen in dieser Schreibweise folgenden 


120, (01 J= 1, (11 }= 2,... {nl J= n«1 
= -2,...{1-n} = -(n+1) 
- Es treten auch halbzahlige Züge auf: 
..ÍínI n1] 2 n + 1/2 
-110) = -1/2, ... [-(n+1) 1-п) = «(n + 1/2) 


011) = 1/2, {0 1 1/2} = 1/4, (0 1 1/4) = 1/8, ... (0 | 1/2)n) = 1/2)(n+1) 
- verallgemeinerte Zweierpotenzen: 
p/2)n I (p+1)/2)n} = (2р+1) / 2)(n+1), Beispiel: (1/2 1 3/4) - 5/8 


{x ly} = z Falls es die Zahl z gibt, so ist z die einfachste Zahl, die 
strikt zwischen x und y liegt. Je einfacher eine Zahl, desto näher 
iegt sie an der Wurzel des Zahlenbaums aus Bild 5. 


gen nach einigen Ästen des 
Baumes abzubrechen und zu 
versuchen, die dann entstande- 
ne Situation zu bewerten. Da 
diese Bewertung nur eine Ab- 
schátzung sein kann, müssen 
wir uns nicht um unsere seltsa- 
men Nim-Zahlen kümmern, 
sondern es genügt vollkom- 
men, sich auf ganze Zahlen zu 
beschränken. Auch hier gilt 
wieder, je größer die Zahl, um 
so besser für den Inhaber der 
bewerteten Stellung. Logi- 
scherweise heißt dies, daß der 
Gegner versucht möglichst klei- 
ne Zahlen (aus unserer Sicht) 
als Bewertung zu erreichen. 
Die Bewertung selbst ist dabei 
die größte Schwierigkeit, denn 
um die Bewertung anhand ei- 
ner Spielposition durchzufüh- 
ren (die auch noch relativ kom- 
pliziert sein kann), müssen wir 
das in Frage stehende Spiel gut 
beherrschen, wir müssen also 
Experten für dieses Spiel sein. 

Nicht umsonst wird die Pro- 
grammierung von Dame- und 
Schachspielen den Bereichen 
der Künstlichen Intelligenz und 
den Expertensystemen zuge- 
ordnet. Die Erfahrung in der Be- 
wertung der Situation läßt sich 
auch durch keinen noch so gut 
programmierten Spielbaum 
oder andere Tricks ausglei- 
chen, denn ist erst einmal eine 
Situation falsch bewertet wor- 
den, so kann nichts unseren 
Spielbaum davon abhalten, 
diese falsche Bewertung bis 
nach oben an die Wurzel durch- 
zureichen, was natürlich zu 
vollkommen unsinnigen Zügen 
führen kann. Da zur Bewertung 
der jeweiligen Situation Exper- 
tenwissen vonnöten ist, soll hier 
auch nicht näher darauf einge- 
gangen werden (hier geht es 
ausschließlich um die mathe- 
matischen Grundlagen). Als 
Kriterien können etwa die An- 


Knoten-Nunner za Beuertung 
ЕЛЕС 


alpha 


zahl der Figuren, deren Kon- 
zentration um bestimmte Stel- 
len, deren Bewegungsfreiheit 
und ähnliches gelten. Bei pro- 
fessionellen Dameprogram- 
men werden teilweise bis zu 50 
Kriterien zur Bewertung einer 
Position zu Rate gezogen. So- 
mit haben wir also klar erfaßt: 
Ein Spielprogramm (für ein 
strategisches Spiel) muß die fol- 
genden Programmteile enthal- 
ten: eine Bewertungsfunktion, 
die es erlaubt, der an die Funk- 
tion übergebene Position eine 
(ganze) Zahl zuzuordnen. Die- 
se Zahl ist um so größer, je bes- 
ser die Position für den Spieler 
ist und um so kleiner, je besser 
die Position für den Gegner ist. 
In unserem Beispiel (Listing 2 
und Bild 13) wird die Bewertung 
einfach aus einem Feld über- 
nommen. Als weiteres Element 
wird ein Zuggenerator benötigt, 
der alle - von der aktuellen Po- 
sition aus - möglichen Züge er- 
kennt, die wir vornehmen kön- 
nen. Auch hier beschränkt sich 
unser Beispiel: In jeder Situa- 
tion sind hier drei Züge möglich. 

Wir verfügen für unser Pseu- 
do-Spiel also über einen Zug- 
generator und über eine Bewer- 
tungsfunktion. Nun müssen wir 
den Spielbaum durchlaufen, 
um den für uns günstigsten Zug 
zu finden. Dazu wird die Funk- 
tion Spielbaum aufgerufen. Be- 
vor diese sich rekursiv aufruft, 
erzeugt der Zuggenerator die 
sich aus den möglichen Zügen 
ergebenden neuen Positionen, 
die als Ausgangspositionen 
dem Zuggenerator beim rekur- 
siven Aufruf übergeben wer- 
den. Nach einer bestimmten, 


50 


vorher festgelegten Anzahl von 
rekursiven Aufrufen wird die 
Bewertungsfunktion aufgeru- 
fen, die der entstandenen Posi- 
tion eine (ganze) Zahl zuordnet. 
Abhängig von der Anzahl der 
Rekursionen wären auf dieser 
untersten Ebene entweder wir 
oder unser Gegner am Zug ge- 
wesen. Entsprechend wird ei- 
ner Position eine Ebene höher 
im Baum das Maximum oder 
das Minimum der Bewertungen 
der Züge übergeben, die als 
Optionen dieser Position mög- 
lich sind. Eine Ebene höher 
wiederholt sich dieses Spiel, 
mit,dem Unterschied, daß der 
andere Spieler am Zug ist; ent- 
sprechend wird das Maximum 
oder das Minimum übergeben. 

So wechseln sich auf dem 
Weg nach oben zur Wurzel des 
Baumes hin immer die Bildung 
von Maximum und Minimum 
auf den jeweiligen Ebenen ab. 
Um am Ende zu entscheiden, 
welcher Zug ausgeführt werden 
soll, muß neben der Bewertung 
auch die Option, der diese Be- 
wertung zugeordnet wird, mit 
nach oben übergeben werden. 

Die Tatsache, daf sich Bildung 
von Maximum und Minimum 


Beachte: 
alpha = 


abwechseln, birgt eine weitere 
Chance zur Optimierung des 
Berechnungsverfahrens. Dazu 
dienen zwei weitere Parameter, 
die der Funktion Spielbaum 
übergeben werden. Diese Pa- 
rameter haben traditionell die 
Namen »alpha« und »beta«. 
Hatten wir in der einen Ebene 
etwa das Maximum zu bilden, 
und nehmen wir an, daß dieses 
Maximum, bei der im Spiel- 
baum zuerst durchlaufenen 
Option dieser Ebene 5 betrug. 

Іп der Ebene darüber soll das 
Minimum gebildet werden. Ist 
bei der náchsten Position, von 
deren Optionen das Maximum 
gebildet werden muß, der erste 
Wert gróBer als 5, so wissen wir, 
daB das Maximum ebenfalls 
größer als 5 ist. Da in der Ebene 
darüber das Minimum gesucht 
wird und der Wert 5 vorhanden 
ist, kann dieses Minimum nicht 
gróBer als 5 sein - daher kón- 
nen wir uns die Bewertung der 
restlichen Optionen dieser Po- 
sition sparen. 

Ein analoges Vorgehen gilt 
natürlich auch, wenn die untere 
Ebene eine Bildung des Mini- 
mums erfordert und die Ebene 
darüber Maxima bildet. Ent- 


Bild 13. 


Der Spiel- 
REX baum zu 
Listing 2 


Ebene 


sprechend diesen beiden Fäl- 
len sind die beiden Parameter 
»alpha« und »beta« wie in Tabel- 
le 2 angegeben zu setzen. Mit 
Hilfe dieser beiden Parameter 
ist es in günstigen Fállen móg- 
lich, bis zu 50 Prozent der Op- 
tionen aus logischen Gründen 
auszuschlieBen und damit Re- 
chenzeit zu sparen. 

Die beschriebenen Algorith- 
men kónnen selbstverstándlich 
auf ein beliebiges Spiel ange- 
wendet werden, solange dieses 
unter logischen ‚Gesichtspunk- 
ten untersucht werden kann 
(Baller- und Action-Spiele las- 
sen sich nur schwer fassen). 
Sie brauchen dazu nur die ge- 
nannten Optimierungen in den 
Zuggenerator Ihres Spiels ein- 
bauen. 

Auf diese Art versehen Sie Ihr 
Spiel mit »logischen Überle- 
gungen«, auch ohne Jahrzehn- 
te auf den nächsten Gedanken- 
gang warten zu müssen. so 


Jürgen Singer arbeitet im Institut für Strö- 
mungsmechanik an der Universität Erlangen- 
Nürnberg. Sie können ihn über unsere Ver- 
lagsanschrift erreichen (Markt&Technik Ver- 
lag AG, Redaktion Sonderhefte, z.Hd. Herrn 
Jürgen Singer, Hans-Pinsel-Straße 2, 8013 
Haar bei München). 


Der Alpha-Beta-Algorithmus 


Bedingung 


Max-Ebene 


Min-Ebene 


Aktuelle Bewertung > alpha 
Aktuelle Bewertung < alpha 


alpha = aktuelle Bewertung 


Abbruch 


Aktuelle Bewertung > beta 
Aktuelle Bewertung < beta 


Abbruch - 


beta = aktuelle Bewertung 


Tabelle 2. Mit dem Alpha-Beta-Algorithmus optimieren Sie die Suche nach dem optimalen Zug 
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Literatur zum Thema 


Zur Spieltheorie gibt es inzwischen relativ umfassende Fachliteratur, wir haben einige für Sie ausgewählt: 


1. Mathematik 


John H. Conway; Über Zahlen und Spiele; Vieweg Verlag 1983 
Berlecamp, Conway, Guy; Gewinnen - Strategien für mathematische 
Spiele, 

- Band 1: Von der Pike auf, Vieweg Verlag 1985 

- Band 2: Bäumchen-wechsle-dich, Vieweg Verlag 1986 

- Band 3: Fallstudien, Vieweg Verlag 1986 

- Band 4: Solitairespiele, Vieweg Verlag 1985 


spielbaun.c 
status: released, in use 
compilation: le -Lm spielbaum.c 


language: Lattice C 5.02 
system: AmigaDos, Kick 1.3 
version: 1.0 (25-Aug-89) 


(с) 1989 Jürgen K. Singer, Nürnberg 


#include <stdio.h> 
#include <stdlib.h> 
#include <math.h> 


#define MAXX 4 


typedef struct 
( 

int 1х; 

int ly ; 

int тх; 

int ry ; 
] Position ; /* Position ist gegeben durch Spalte und Reihe des Stei- 
nes %/ 

/* von >>Links<< und >>Rechts<< */ 


/%------------------- Prototypen --- 
double simplest( double 1, double Y) ; 
double Bewertung( Position p) ; 


int err = 0; 


Berechnet die > >einfachste<< Zahl x, für die gilt 1 < x < г. 
Dabei ist >>einfach< < definiert als > >möglichst nahe der 
Wurzel im Zahlenbaum« <. 

Falls linker'Rand rechts vom rechten Rand, gibt es keine derartige 
Zahl.Die zugehörigen theoretischen Betrachtungen finden sich in: 
Berlekamp, Conway, Guy; Gewinnen - Strategien für mathematische 
Spiele;Band 1: Von der Pike auf, Vieweg Verlag 1985. 


Argumente: linker und rechter Intervallrand 
Funktionswert: a) falls err = 0: einfachste Zahl im Intervall 
b) falls err = -1: 0, da ungültige Argumente 
------------------і----------------------------------------- ж/ 
( 
double x ; 
double a ; 


if( 1 >= r ) /* Es gibt keine derartige Zahl x,setze Fehlercodek/ 


| 


err = -1 ; 
return 0.0 ; 


) Ж0<-1<г»/ 
floor(1+1) ; х>-г;а/-2.0) 
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2. Computer 


Stefan Berchtold; Dame mit Strategie; in C'T-Magazin für Computer- 
technik, 8/89 Seite 114ff, Heise Verlag. 

A. K. Dewdney; Meisterliche Dameprogramme; in Verständliche For- 
schung: Computer-Kurzweil; Spektrum der Wissenschaft Verlagsge- 
sellschaft 1988. 

D. N. L. Levy; Computergames |; Springer Verlag. 

D. М. L. Levy; Computergames II; Springer Verlag. 


else if( r <=0) ml epes 0 X/ 
for( x = ceil(r-1) ; x <= 1 ; a /= 2.0 ) 
x48; 
else /*r <0<1%/ 
x= 0.0 5 
return x ; 
| /* simplest */ 


double Bewertung( Position p ) 


Bewerte eine gegebene Position. Diese Funktion ruft sich selbst 
solange auf, bis eine einfach zu bewertende Position erreicht ist; 
dies ist hier der Fall, wenn kein Sprung mehr möglich ist. 


double b ; 
Position pl ; /* Option für >>Links<< %/ 
Position pr ; /* Option für >>Rechts<< */ 


if( p.lx > p.rx ) /* kein Sprung mehr möglich:Bewertung ist nun*/ 
b = MAXX + 1 - р.1х - p.rx ; /* einfach Differenz der Züge */ 
else /* Noch keine einfache Situation erreicht %/ 


[ 


pleprep 
if( (р.1х == p.rx) && (p.ly == (p.ry+1)) && (p.ry > 1) ) 
pl.ly -= 2 ; /* Sprung möglich */ 
else 
р1.1х += 1 ; /* >>Links<< zieht ein Feld nach Ost */ 
pr.rx -= 1; /* >>Rechts<< zieht ein Feld nach West */ 
b = simplest( Bewertung(pl), Bewertung(pr)) ; 


] 
return b ; 
] /* Bewertung */ 


#define FMTSTR "Position Links: %d, Rechts: %d, Bewertung %1f\n” 
void main( int argo, char *argv[]) 

Berechne den Spielbaum für 3 * MAXX Springer. Argument 1 - Position 
von >>Links<< in Reihe 3 (1 <= 1x <= MAXX), Argument 2 = 


Posttion von >>Rechts<< in Reihe 2 ( 1 <= rx <= MAXX). 
= тыу; 


Position p ; 


if( argc 1= 3 ) exit(-1) ; 


р1у-3; /* >>Links<< beginnt in Reihe 3 %/ 
рту-2; /* >>Rechts<< beginnt in Reihe 2 */ 
р.1х = atoi(argv[1]) ; /% Spalte von >>Links<< X*/ 
р.гх = atoi(argv[2]) ; /% Spalte von >>Rechts<< %/ 


printf( FMTSTR,p.1x,p.rx,Bewertung(p)) ; 
if( err ) printf("Bewertung ungültig!\n”) ; 
] /* main */ 


/* Listing 1: Berechnung des Spielbaumes zu Bild 9 */ 


Listing 1. 
Die Berechnung eines 
Spielbaums 
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language: Lattice C 5.02 
system: AmigaDos, Kick 1.3 
version: 1.0 (03-Sep-89) 


alphabeta.c 
status: released 
compile: lc -Le alphabeta.c 


(с) 1989 Jürgen K. Singer, Nürnberg 


Berechnung des Spielbaumes für ein Pseudo-Spiel mit Hilfe des 
alpha - beta - Algorithmus nach dem Mini-Max-Prinzip 


-*/ 


#include <stdio.h> 
#include <stdlib.h> 
#include <limits.h> 


+#1f !defined(NIL) 
#define NIL OL 
#endif 


/* maximale Rekursionstiefe = Spielstufe */ 
#define MAXREKURS 3 


/* soll Minimum oder Maximum gebildet werden? */ 
#define MINIMAX(x) ( (x) & 1 ) 


typedef int Stellung ; /* Figurenkonstellation */ 


struct option [ 
Stellung s ; /* Figurenkonstellation */ 
b ; /* Bewertung */ 


typedef struct option Option ; /* mgliche Züge */ 


/% Prototypen %/ 

Option Spielbaum( Option alt, int RekTiefe, int alpha, int beta) ; 
int Zuggenerator( Option alt, Option **neu ) ; 

void Bewertung( Option Walt ) ; 


void main(int argo, char Xargv[]) 


| 


Option Start ; 
Option Zug ; 

int alpha = INT. MIN ; 
int beta = INT MAX ; 


Zug = Spielbaum( Start, 0, alpha, beta) ; 
printf( "Optimaler Zug: Stellung: %d Bewertung: %d \n”,Zug.s, 


Dummy - Funktionen 
int Zuggenerator( Option Start, Option **neu) 
( 
static Stellung nr 20; 
int Anzahl ; 
inti; 


Anzahl = 3 ; 
*neu = (Option *) malloc( Anzahl * sizeof(Option) ) ; 
for( i=0; 4 < Anzahl ; i+ ) 
{ 
(neu + 1)->s = ar ; 
(neu + 1)->b = 0; 
} 
return Anzahl ; 


) 


void Bewertung( Option Xo ) 
{ 
/* Dimension = Gesamtzahl der möglichen Züge %/ 
static int b[/* (summe 1=0 ... MAXREKURS (21)) - 1%/] = 


28, 29, 30, 31, 
16, 17, 18, 19, 


^ 5 6, 7, 


Option Spielbaum( Option alt, int RekTiefe, 
( 

Option *neu = NIL ; 

Option Zug ; 

Option Bester ; 

int Zugzahl ; 

int 13 


alpha, int beta) 


if( RekTiefe < MAXREKURS ) /* Noch nicht auf unterster Ebene */ 
[ ` 
if( MINIMAX(RekTiefe) ) /* min-Ebene */ 
Bester.b = INT_MXAX ; 
else /* max-Ebene */ 
Bester.b = INT MIN ; 
Zugzahl = Zuggenerator( alt, &neu) ; /* Finde alle mögl. Züge 


for( 1 = 0; 1 < Zugzahl ; i++ ) /* Finde zu Jedem möglichen 
Zug */ 
{ /* dessen Optionen */ 

Zug = Spielbaum( neu[i], RekTiefe + 1, alpha, beta) ; 

if( MINIMAX(RekTiefe) ) /* min - Ebene */ 

{ 


if(Bester.b > Zug.b) /* neuer bester Zug gefunden */ 


Bester.b = Zug.b ; 
Bester.s = (neu + 1)->s ; 
beta = Bester.b ; 


if( alpha > Zug.b) break ;/*Züge können nur schlechter*/ 
) /* sein: Abbruch */ 

else /* max - Ebene */ 

{ 


if(Bester.b < Zug.b) /% neuer bester Zug gefunden %/ 


Bester.b = Zug.b ; 
Bester.s = (neu + 1)->s ; 
alpha = Bester.b ; 


if( beta < Zug.b) break ; /* nur schlechtere Züge: 
Abbruch */ 
] 
] 
free( neu ) ; /* vergessen der nicht benutzten Optionen */ 
return( Bester ) ; 


} 
else/* unterste Ebene erreicht: Bewerte die entstandene Position*/ 
{ 

Bewertung( &alt ) ; 

return( alt ) ; 


Listing 2. 
Die Umsetzung des 
Alpha-Beta-Algorithmus in C 


AMIGA-SONDERHEFT 7 


Know-How 


Sprites unter der Lupe 


COLA,FANTA,SPRITE 


Von Arno Gólzer 


as wáre ein schnelles 
Actionspiel ohne 
Sprites? Richtig, ein 


fuBkrankes Actionspiel. Diese 
kleinen Objekte sind das Salz in 
der Suppe des Spieleprogram- 
mierers. 

Sprites sind kleine, frei be- 
wegliche Grafikobjekte, die be- 
vorzugt in Spielen eingesetzt 
werden. Der Amiga hált einige 
interessante Routinen bereit, 
die das Arbeiten mit diesen »gu- 
ten Geistern« des Spielers 
leichter machen. Auf eine Pro- 
grammierung der Hardware 
können Sie daher in den mei- 
sten Fällen verzichten - im Ge- 
gensatz zu gewissen Steinzeit- 
computern, denen der Pro- 
grammierer nur unter ver- 
schärfter POKErei eine dieser 
Miniaturgrafiken entlocken 
konnte. 

Spiele sind jedoch nicht 
mehr die einzigen Einsatzmög- 
lichkeiten für Sprites. Längst 
nutzt man die Vorteile auch in 
Text- oder Grafikprogrammen. 

Auch die Arbeit auf dem Ami- 
да, speziell mit der Workbench, 
ist ohne Sprites'nur schwer vor- 
stellbar: Versuchen Sie einmal, 
kurze Zeit ‘ohne Mauszeiger 
auszukommen. Schnell stellen 
sich — Entzugserscheinungen 
ein. Moment mal... Sprites... 
Mauszeiger??? Sie vermuten 
richtig. Der Mauszeiger ist 
nichts anderes als einer der 
acht zur Verfügung stehenden 
Hardwaresprites des Amiga- 
Grafiksystems. Sprites sind von 
0 bis 7 durchnumeriert, dabei 
ist Nummer 0 für den Pointer re- 
serviert. 

Natürlich wissen Sie, daß Sie 
ihn beispielsweise mit dem 
Preferences-Programm belie- 
big verándern kónnen. Aber 
auch vom eigenen Programm 
aus ist das sehr einfach móg- 
lich und - gerade für Spiele - 
durchaus interessant. Unser 
Beispielprogramm »HotBot- 
tom« (Listing 2) macht dafür von 
der "Betriebssystem-Funktion 
SetPointer() Gebrauch: 


SetPointer(&Window, . 
&data[0],h,b,x,y); 


Die Funktion erlaubt die Defi- 
nition eines eigenen Mauszei- 
gers für jedes Fenster. Dieser 
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Spiele ohne Sprites 
schmecken wie Ok- 
toberfest ohne Bier, 
wie Sommer ohne 
Sonne, wie Kau- 
gummi ohne Zu- 
cker, wie... 


Zeiger ist immer dann sichtbar, 
wenn sich das jeweilige Fenster 
im aktivierten Zustand befindet. 
Die Parameter dieser Funktion 
von links nach rechts: a) die 
Adresse des Fensters, in dem 
der neue Pointer sichtbar sein 
soll (»&Windows), b) die Adres- 
se des Datenblocks, der die 
Pointerdaten enthált (»&data«), 
c) die Höhe des Pointers (»h«), 
d) die auf maximal 16 Pixel be- 
schränkte Breite (»b«) und e/f) 
die x/y Koordinaten (»x,y«) des 
sogenannten Hot-Spots, be- 
züglich der linken oberen 


Sprite-(Pointer-)Ecke. 


Register für Farbe 


Sprites 


Spritepaar) auf die gleichen 
Farbregister zugreifen. Die Far- 
ben des Pointers, es handelt 
Sich ja um Sprite Nummer О, fin- 
den Sie in den Farbregistern 17 
bis 19. 

Das oben angesprochene 
Daten-Array enthált als Be- 
schreibung für jede Zeile des 
Pointers zwei hintereinander 
liegende, 16 Bit breite Werte. 
Stellen Sie sich die beiden Wer- 
te in binárer Form untereinan- 
der vor, etwa so: 


%1100101001110011 
%1001111001100110 


Lesen Sie die senkrecht 
übereinanderliegenden Bits 
von unten nach oben. Liegen 
zwei Nullen (00) übereinander, 
so ist das Sprite an dieser Stelle 
der Zeile transparent. Lesen 
Sie (von unten nach oben) die 
Bits 01, so ist dieser Punkt in der 
Farbe des ersten (%01-1) zu- 
ständigen Registers gefärbt 
(siehe Tabelle 1). Die Bitkombi- 


O und 1 
2und 3 
4und5 
6 und 7 


Tabelle 1. Die Farbregisternummern der Sprites 


Als Hot-Spot bezeichnet man 
die »empfindliche« Stelle im 
Mauszeiger, mit der Sie bei- 
spielsweise ein Workbench- 
Objekt anwählen können. Un- 
klar hierbei ist nur noch das 
Aussehen des Datenblocks, 
dessen Adresse die Funktion 
als zweiten Parameter erwartet. 
Es handelt sich um ein 
UWORD-Array im Chip-Memo- 
ry, dessen beiden ersten und 
beiden letzten Einträge gleich 0 
sein müssen: 


UWORD Data[]- 


10:05 22 0,015 
Zwischen diesen für das 
System reservierten Array- 


Elementen befindet sich die 
»Beschreibung« des Pointer- 
sprites. Wie sieht diese Be- 
schreibung aus? Ein Hardware- 
sprite besteht aus maximal drei 
Farben. Aus Tabelle 1 geht her- 
vor, daß immer zwei Sprites (ein 


nation 10 verweist auf das zwei- 
te (%10=2) und schließlich die 
Kombination 11 auf das dritte 
(%11=3) Farbregister. 

Schauen wir uns die Daten 
des Pointers in Listing 2 an. Sie 
finden sie gleich am Anfang des 
Listings im UWORD-Array 
PointerDat[]. Die erste Zeile, be- 
stehend aus OxFFFF und 0, ist 
komplett in der Farbe des Regi- 
sters 17 gefärbt: 


%1111111111111111 
OxFFFF 

%0000000000000000 
0x0000 


Denn in jeder Spalte finden 
wir, von unten nach oben gele- 
sen, die Bitkombination 01. Bi- 
när 01 entspricht dezimal 1, das 
erste Farbregister des Sprites 0 
ist 17. Die zweite Zeile, 0 und 
OxFFFF, ist in der Farbe des Re- 
gisters 18 (%10) und die dritte 
Zeile, zweimal OxFFFF, in der 


des Farbregisters Nummer 19 


(9/011) gefärbt. 
Der drei Zeilen hohe Pointer 
enthált keine transparente 


(%00) Zeile. Vor und hinter den 
für die drei Zeilen notwendigen 
sechs Elementen sind jeweils 
die beiden O-Eintráge aufge- 
führt. Beachten Sie bitte, daß al- 
le Spritedaten, also auch die 
des Pointers, im Chip-Memory, 
also den unteren 512 KByte des 
Arbeitsspeichers, liegen müs- 
sen. In Listing 2 kopieren wir die 
Daten mit der CopyMem(-Funk- 
tion »nach unten«. Ein UWORD- 
Datenblock, wie soeben be- 
schrieben, muB auch bei der 
Definition eines eigenen Spri- 
tes vereinbart werden. Wichtig 
ist dabei, daB Sie für jedes Spri- 
te einen eigenen Datenblock 
vereinbaren, auch wenn Sie 
mehrere gleich aussehende 
Sprites darstellen móchten. 

Zu dem Daten-Array kommt 
bei der Sprite-Definition die 
Festlegung der sogenannten 
SimpleSprite-Struktur (Listing 
1) hinzu, deren Elemente die 
Form und die Position des Spri- 
tes beschreiben. 

Als erste Komponente finden 
wir dort die Adresse des Sprite- 
Datenblocks: »posctldata«. Die 
Hóhe des Sprites tragen wir in 
»height« ein - wie erwáhnt dür- 
fen Sprites beliebig hoch sein. 
Eine Variable für die Breite ist in 
der Struktur nicht enthalten - 
Hardware-Sprites haben ja eine 
fest definierte Breite von 16 Pi- 
xel. Für die Arbeit mit breiteren 
Objekten muß man entweder 
mehrere Sprites zusammenfü- 
gen oder aber auf gänzlich an- 
dere Objekte, z.B. BObs (»Blit- 
ter-Objects«) zurückgreifen. Die 
Sprite-Dimensionen sind von 
der gewählten Display-Auflö- 
sung unabhängig. Die Größe 
eines Sprite-Pixels entspricht 
immer der Größe eines Bild- 
schirm-Pixels im Lores-Modus. 

Die SimpleSprite-Struktur- 
Variablen x und y enthalten die 
Position des Sprites. Sie wer- 
den ständig aktualisiert, so daß 
Sie hier jederzeit die Position ei- 
nes Sprites erfahren können. 
Die letzte Komponente namens 
»num« steht für die Sprite- 
Nummer (siehe unten). 

Die Beschreibung des Spri- 
tes ist somit abgeschlossen. 
Vor dessen Darstellung muß 
aber noch der Screen, oder all- 
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gemein das Display, für die Ver- 
wendung von Sprites vorberei- 
tet werden. Dies geschieht 
durch das Setzen des View- 
Modus Flags »SPRITES«. Wie 
aus Listing 2 hervorgeht, ist der 
Workbenchscreen bereits auf 
Sprites vorbereitet, das Flag 
muß nicht explizit gesetzt wer- 
den. 

Nachdem alle Vorbereitun- 
gen abgeschlossen sind, mel- 
det GetSprite() die Kleingrafik 
an: 


SpriteNr-GetSprite 

(&Sprite,nr); 

GetSprite() verlangt als Para- 
meter einen Zeiger auf die 
SimpleSprite-Struktur und die 
gewünschte Spritenummer. Ist 
das Sprite mit der angegebe- 
nen Nummer noch frei, so ent- 
spricht der Returnwert der 
Funktion dieser Nummer. Get- 
Sprite() kehrt mit dem Wert -1 
zurück, wenn das Sprite bereits 
reserviert war. Bei der Angabe 
von -1 als Spritenummer-Para- 
meter, liefert die Funktion die 
Nummer des ersten freien Spri- 
tes. 

Wie weiter oben bereits an- 
gedeutet, kónnen wir auf dem 
Amiga bis zu acht Hardware- 
Sprites, mit den Nummern 0 bis 
7, definieren. Bei der Wahl der 
Spritenummer sollten Sie fol- 
gendes beachten: Wenn die 
Sprites so auf den Bildschirm 
positioniert sind, daB sie sich 
teilweise verdecken, ist das 
Sprite mit einer niedrigeren 


Melde, wenn gesetzt, 
Kollision mit: 


Sprite (6 und) 7 
Sprite (4 und) 5 
Sprite (2 und) 3 
Sprite (0 und) 1 
Plane 6 
Plane 5 

Plane 4 T- C o 
Plane 3 

Plane 2 

Plane 1 

gesetztem Bit der Plane 6 
gesetztem Bit der Plane 5 
gesetztem Bit der Plane 4 
gesetztem Bit der Plane 3 
gesetztem Bit der Plane 2 
gesetztem Bit der Plane 1 


9 
8 
n 
6 
5 
4 
3 
e 
1 
0 


stimmung der Spritenummer 
kennen. Das Gegenstück zu 
GetSprite) ist — FreeSprite 
(SpriteNummer). Diese Funk- 
tion lóscht das Sprite mit der 
angegebenen Nummer vom 
Display und meldet es beim Sy- 
stem wieder ab. Somit ist es für 
die Neuverwendung - eventuell 
von einem anderen Programm 
- wieder frei. Der Parameter ist 
die von GetSprite() gelieferte 
Spritenummer. 

Móchten Sie nicht nur ein, 
sondern alle Sprites auf einen 
Schlag verschwinden lassen, 
hilft Ihnen das Makro OFF. . 
SPRITE, indem es einfach den 
DMA-Kanal abschaltet. Das 
Gegenstück ON. SPRITE 
stellt den Urzustand wieder her. 

Nach dem Aufruf der Get- 
Sprite()-Funktion ist das Sprite 
noch nicht sichtbar. Für die Dar- 
stellung und die Bewegung der 
Sprites ist 
MoveSprite 

(&VP, &SSprite,x,y); 


zustándig. Der erste Parameter, 
die Adresse »VP«, zeigt auf die 
ViewPort-Struktur des Displays. 
Pointer »SSprite« verweist auf 
die SimpleSprite-Struktur, die 
das Sprite beschreibt. Die rest- 
lichen Parameter stehen für die 
X/Y-Position der linken oberen 
Sprite-Ecke, bezüglich der lin- 
ken oberen Ecke des Displays. 
Mit dieser Funktion kommt 
auch endlich - im wahrsten Sin- 
ne des Wortes - Bewegung ins 
Spiel. Setzen Sie MoveSprite() 


Melde, wenn gelóscht, 
Kollision mit: 


Sprite 6 
Sprite 4 
Sprite 2 
Sprite 0 


gelóschtem Bit der Plane 6 
gelóschtem Bit der Plane 5 
gelóschtem Bit der Plane 4 
gelóschtem Bit der Plane 3 
gelóschtem Bit der Plane 2 
gelóschtem Bit der Plane 1 


Tabelle 2. Über das Register »CLXCON« bestimmen Sie, 
welche Sprite-Kollisionen Sie gemeldet wünschen 


Nummer immer vor dem mit ei- 
ner hóheren Nummer zu se- 
hen. 

Diese Prioritáten sind in der 
Hardware festgelegt und somit 
nicht veránderbar. Weiter un- 
ten, bei der Besprechung der 
Kollisionserkennung, lernen 
Sie weitere Kriterien für die Be- 
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in den Rumpf einer Schleife 
und ándern Sie bei jedem 
Durchgang die Werte x und y. 
Positive x-Werte lassen das 
Sprite nach rechts wandern, 
positive y-Werte veranlassen es 
zu einer Bewegung nach unten. 
Fügen Sie jedoch beim ersten 
Testen eine Warteschleife ein, 


denn die Bewegungen der Spri- 
tes erfolgen in sehr hoher Ge- 
schwindigkeit. 

Manchmal ist es notwendig - 
beispielsweise für eine Explo- 
Sion - das Aussehen eines Spri- 
tes zu verándern. Glücklicher- 
weise bleibt uns hierfür die um- 
stándliche Sequenz des Freige- 
bens und der Neudefinition er- 
spart: 

ChangeSprite(&VP, 
&SSprite,&data[0]); 


Diese Funktion verändert 
das Aussehen des Sprites der 
von der SimpleSprite-Struktur, 
auf die der Pointer »SSprite« 
verweist, beschrieben wird. Der 


Ereignis (Kollision von): | 


ungenutzt 


Sprites. Die Farben erreichen 
Sie über die Farbregister 17 bis 
31. Die beiden oberen der vier 
Bits werden von dem Sprite des 
Paars mit der höheren Nummer 
bestimmt. 

Die ganze Farbenpracht wird 
jedoch erst nach der Definition 
eines Sprite-Paares als At- 
tached-Sprite sichtbar. Setzen 
Sie hierzu in beiden Daten- 
Arrays, im zweiten UWORD, 
das Attached-Bit: 


Data[1]=SPRITE_ATTACHED; 


Nachdem Sie Aussehen und 
Bewegung der Sprites beliebig 
beeinflussen können, haben 


ea ae 
NUORO 


= 


Sprite 4 (oder 5) mit Sprite 6 (oder 7) 
Sprite 2 (oder 3) mit Sprite 6 (oder 7) 
Sprite 2 (oder 3) mit Sprite 4 (oder 5) 
Sprite 0 (oder 1) mit Sprite 6 (oder 7) . 
Sprite 0 (oder 1) mit Sprite 4 (oder 5) 
Sprite 0 (oder 1) mit Sprite 2 (oder 3) 


10 
9 
8 
is 
6 
§ 
4 
3 
2 
1 
0 


BitPlane (gerade Nummer) mit Sprite 6 (oder 7) 

BitPlane (gerade Nummer) mit Sprite 4 (oder 5) 

BitPlane (gerade Nummer) mit Sprite 2 (oder 3) 

BitPlane (gerade Nummer) mit Sprite 0 (oder 1) 

BitPlane (ungerade Nummer) mit Sprite 6 (oder 7) 

BitPlane (ungerade Nummer) mit Sprite 4 (oder 5) 

BitPlane (ungerade Nummer) mit Sprite 2 (oder 3) 

BitPlane (ungerade Nummer) mit Sprite 0 (oder 1) 

BitPlane (gerade Nummer) mit BitPlane (ungerade Nummer) 


Tabelle 3. Der Inhalt des Registers »CLXDAT« berichtet über 


das Kollisionsereignis 


dritte Parameter zeigt auf das 
Array mit den neuen Spriteda- 
ten. Auch hier denken Sie bitte 
daran: Daten im Chip-Memory 
und je zwei UWORD-Variablen 
vor und nach den eigentlichen 
Datenblocks einfügen. Wie aus 
Tabelle 1 ersichtlich ist, greifen 
immer zwei Sprites auf die glei- 
chen Farbregister zu. Ein sol- 
ches Spritepaar kann man zu 
einem einzigen Sprite verbin- 
den, einem sogenannten 
Attached-Sprite. Der Vorteil: 
Attached-Sprites können in 15 
Farben dargestellt werden. Wie 
bitte, zweimal drei Farben (die 
zudem noch gleich sind) erge- 
ben plötzlich 15 verschiedene 
Farben? Genau. Beide Sprites 
müssen dazu an die gleiche 
Bildschirmposition gebracht 
werden. Da eine Zeile eines 
Sprites durch zwei UWORDs 
dargestellt wird, liegen bei zwei 
positionsgleichen Sprites vier 
UWORDS übereinander. Mit vier 
übereinanderliegenden Bit, die 
einem Pixel eines Attached- 
Sprites entsprechen, können 

= 16 Zustände dargestellt 
werden. 

Das ergeben 15 Farben (plus 
eine transparente) für Attached- 


Sie sicher schon die ersten 
Ideen für Ihr neuestes Amiga- 
Spiel notiert. Vielleicht handelt 
es sich um ein Geschicklich- 
keitsspiel wie dieses: Der Spie- 
ler hat die Aufgabe, durch einen 
geschickten Wurf mit einem 
Pfeil, möglichst mittig eine 
mehrfarbige Zielscheibe mit 
konzentrischen Kreisen zu tref- 
fen. 

Mit den bisher erhaltenen In- 
formationen läßt sich dieses 
Spiel relativ problemlos reali- 
sieren - bis zur Auswertung. 
Wie stellt man fest, in welchem 
Farbring sich der Pfeil befin- 
det? Oder allgemeiner defi- 
niert: Wie stellt man die Kolli- 
sion eines Hardware-Sprites 
mit dem Hintergrund oder ei- 
nem anderen Sprite fest? 

Die Kollisionsabfrage mit 
dem Hintergrund setzen wir mit 
der Grafik-Funktion Read 
Pixel( ) um. Für unser Beispiel 
bedeutet das, wir müssen mit 
ReadPixel() die Farbe unter 
dem Pfeil ermitteln und den 
Wurf entsprechend bewerten. 
Das Zusammenprallen zweier 
Sprites könnten wir über deren 
Positionen ermitteln. Ein Bei- 
spiel: Möchten Sie kontrollie- 
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ren, ob zwei gleichgroße Ku- 
geln kollidiert sind, so müssen 
Sie ständig prüfen, ob die Mit- 
telpunkte der Kugeln sich näher 
als der Kugeldurchmesser 
sind. 

Beide Methoden haben den 
Vorteil, daß sie sehr einfach zu 
formulieren sind. Sie haben 
aber beide auch einen Nach- 
teil: die Kollisionskontrolle ko- 
stet viel Zeit. Da sie bei jeder 
Sprite-Bewegung durchgeführt 
werden muß, kann sich dies, 
besonders beim Arbeiten mit 
vielen Sprites, durch eine unre- 
gelmäßige Bewegung bemerk- 
bar machen. 

Die optimale Lösung für bei- 
de Fälle machte den Zusatz »in 
den meisten Fällen« in der Ein- 


leitung nötig, denn Abhilfe 
schaffen hier zwei Hardware- 
Register: 


»clxcon« und »сіхааї«. Sie er- 
reichen diese Register über die 
im Headerfile »hardware/cu- 
stom.h« definierte Custom- 
Struktur. Sie enthält namentlich 
die Hardware-Register, die sich 
im Speicher ab der Adresse 
OxDFF000 befinden: 


custom.clxcon=0x41; 


Register clxcon ist fur die 
Kollisions-Kontrolle verantwort- 
lich. Hier legen Sie durch das 
Setzen einzelner Bits fest, wel- 
che Kollisionen registriert wer- 
den sollen. 

Tabelle 1 zeigt die Zusam- 
mengehórigkeit zweier Sprites. 
Auch bei der Kollisionsabfrage 
werden immer zwei Sprites zu 


einem Spritepaar zusammen- . 


gefaßt. Die Sprites mit der gera- 
den (und dadurch kleineren) 
Nummer werden automatisch 
überwacht. Móchten Sie aber 
auch Informationen über die 
anderen Sprites, es sind dies 
die Sprites mit den Nummern 1, 
3, 5 und 7, so müssen Sie dies 
über die oberen 4 Bit des clx- 
con-Registers mitteilen (siehe 
auch Tabelle 2): 


12 13 14 
3 5 


elxcon-Bit: 


Sprite-Nr.: 1 


clxcon-Bit: 15 
Sprite-Nr.: 7 


Durch das Setzen der jeweili- 
gen Bits bestimmen Sie, wel- 
che Sprites Sie kontrollieren 
möchten. Mit den Bits 6 bis 11 
legen Sie fest, welche BitPla- 
nes Sie testen wollen: 


clxcon-Bit: 
Plane-Nr.: 


clxcon-Bit: 
Plane-Nr.: 
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Mittels der restlichen Bits tei- 
len Sie mit, ob Sie eine Mel- 
dung beim Zusammentreffen 
mit einem gesetzen Plane-Bit 
oder einem gelöschten Plane- 
Bit wünschen. 


elxcon-Bit: 
Plane-Nr.: 


elxcon-Bit: 
Plane-Nr.: 


Ein gesetztes Bit bedeutet: 
Meldung einer Sprite-Kollision 
mit einem gesetzten Bit in der 
entsprechenden BitPlane. Ein 
Beispiel macht den Sachver- 
halt verständlicher: Wir arbei- 
ten in einem Screen mit zwei 
Planes und wünschen eine 
Meldung, wenn Sprite 6 mit der 
Farbe aus dem vierten Farbre- 
gister zusammenstößt. 

Sprite 6 ist der Sprite mit der 
kleineren Nummer aus dem 
Sprite-Paar Nummer 4, dem- 
nach interessieren uns die obe- 
ren 4 clxcon-Bit nicht. Da das 
erste Farbregister als Nummer 
0 geführt wird, hat das vierte 
Farbregister die Farbregister- 
Nummer 3 (Farbregister-Nr.: 0, 
1, 2, 3, 4 ... 31). Die entspre- 
chende Farbe erscheint daher 
auf dem Bildschirm, wenn die 
Bits der ersten Plane und die 
Bits der zweiten Plane gesetzt 
sind, denn 3 entspricht binär 
%11. Daher muß сіхсоп folgen- 
dermaßen belegt werden: 


=< 
pa 


clxcon-Bit: 
Koll.-Wert: 
clxcon-Bit: 
Koll.-Wert: 
clxcon-Bit: 
Koll.-Wert: 


0 
= 


-0090-900000u 
= 


OnomMoOwWO-Of 
= 


== EN P äerd OO OH о 


elxcon-Bit: 
Koll.-Wert: 
elxcon-Bit: 
Koll.-Wert: 
clxcon-Bit: 
Koll.-Wert: 


Ein weiteres Beispiel: Sprite 
3 soll in einem Screen mit vier 
Planes an allen Punkten, die in 
der Farbe des Farbregisters 
Nummer 2 gefarbt sind, zusam- 
menstoBen. 

Die Uberwachung des Spri- 
tes mit der ungeraden Nummer 
3 müssen wir anmelden, bevor 
wir es abfragen können. Weiter- 
hin haben wir vier Planes - eine 
Kollision soll aber nur gemeldet 
werden, wenn nur die Bits in der 
zweiten Plane gesetzt sind 
(Farbregisternummer 2 ent- 
spricht binär %10). Um Falsch- 
informationen zu vermeiden, 
verlangen wir ausschließlich 
Meldungen über die zweite Bit- 
plane: 


Know-How 


= 


clxcon-Bit: 
Koll.-Wert: 
clxcon-Bit: 
Koll.-Wert: 
сіхсоп-Вії: 
Koll.-Wert: 


EN 


oOmoocooo2oomrcs 
RUN 


--0P-N00-0 


clxcon-Bit: 
Koll.-Wert: 
clxcon-Bit: 
Koll.-Wert: 
elxcon-Bit: 
Koll.-Wert: 


ооооооооомоо 


Das Ergebnis der Kollisions- 
meldung entnehmen wir den 
unteren 14 Bit des Registers 
clxdat (Bit 15 ist ungenutzt). Die 
Bedeutung der Bits entnehmen 
Sie Tabelle 3. 

Beachten Sie beim Auslesen 
des Registers, daß dieses nach 
dem Lesen sofort gelöscht und 
erst beim nächten Start des 
Elektronenstrahls neu be- 
schrieben wird. 

Betrachten wir uns noch ein- 
mal unsere beiden Beispiele: 
Welche Werte sind bei einer 
Kollision dem clxdat-Register 
zu entnehmen? Beispiel 1: Spri- 
te 6 soll mit den beiden unter- 
sten Planes zusammenstoßen: 


1 


41 
0 
1 
0 
8 
1 
5 
0 
2 
0 


3 
0 
0 
0 
7 
0 
4 
1 
1 
0 


clxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 


= 
SR 


5 
0 
2 
0 
9 
0 
6 
0 
3 
0 
0 
0 


Die Meldung besagt, daß 
Sprite 6 mit einer geraden Bit- 
Plane (Plane 2, 4, 6) und mit ei- 
ner ungeraden BitPlane (Plane 
1, 3, 5) zusammengetroffen ist. 
Da wir іп сіхсоп nur Informatio- 
nen über die beiden untersten 
BitPlanes angefordert haben, 
können wir sicher sein, daß ei- 
ne Kollision stattgefunden hat. 
Wir erfragen sie folgenderma- 
Ben: 
nr=custom.clxdat; 
if( (nr&0x110) ==0x110) { 


Kollision(); 
j YA 


Die Lösung für das zweite 
Beispiel - Sprite 3 soll mit der 
zweiten BitPlane kollidieren 
(überlegen Sie zunächst selbst, 
bevor Sie den Kasten betrach- 
ten): 


ex 
= 
ae 


clxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 


=< 


оооо-оооогмоо 
A 


OoOmooooo-oone 
RS 


O-O0PONOOoow 


clxcon-Bit: 
BitMeldung: 
elxcon-Bit: 
BitMeldung: 
clxcon-Bit: 
BitMeldung: 


Die Meldung lautet: Sprite 3 
(oder 2) ist mit einer geraden Bit- 
Plane zusammengestoßen: 


is (nr&0x40) ==0x40) { 


Sie sehen, hier ist die Mel- 
dung nicht eindeutig (es sei 
denn, es handelt sich um ein 
Attached-Sprite)! Sowohl Sprite 
2 als auch Sprite 3 bringen bei 
dem eingestellten Kontroll-Wert 
die gleiche Meldung. Um mög- 
liche Fehler zu vermeiden, müs- 
sen Sie bereits beim Anmelden 
der Sprites mit GetSprite() die 
Numerierung beachten. 

Nach so viel Theorie ist etwas 
Entspannung bei einem Spiel- 
chen nötig. Testen Sie doch 
gleich einmal das Demopro- 
gramm für Pointer & Sprites, 
»HotBottom« (Listing 2). 

Ein Sprite, in Form eines Balls, 
bewegt sich darin innerhalb ei- 
nes Balkens über das Spielfeld. 
Er reflektiert an den Seiten des 
Feldes und an kreisfórmigen 
Hindernissen. Die Hindernisse 
werden »angenagt«, wobei sich 
die Flugrichtung des Balls verán- 
dert. 

Ihre Aufgabe ist es, dafür zu 
sorgen, daß der Ball den Spiel- 
feldboden nicht berührt. Als 
Hilfsmittel steht Ihnen dafür der 
als Break-Out-Schläger modifi- 
zierte Mauszeiger zur Verfü- 
gung. Dieser ist gemeinerweise 
nur sichtbar, wenn sich der Ball 
in Bodennáhe befindet - und 
auch in der Titelleiste, falls Sie 
das Spiel vorzeitig beenden 
móchten. 

Springt der Ball trotz aller 
Vorsicht doch einmal auf den 
Boden, so wáchst die Game- 
Over-Säule am linken Spielfeld- 
rand ein wenig höher. Säule 
und Balken fárben sich rot, um 
Sie zu warnen, wenn das Spiel- 
ende kurz bevorsteht. 

Einige Punkte des Listings 
sollen nicht unerwáhnt bleiben. 
Betrachten wir uns die Funktion 
OpenW(). Hier werden die Li- 
braries und das Window geöff- 
net, die Sprite-Farben festge- 
legt, Speicher für Chip-Memory 
angefordert und belegt und die 
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SimpleSprite-Struktur mit den 
noch fehlenden Informationen 
über die Lage der Spritedaten 
ergänzt. Hier vereinbaren wir 
auch Speicher für den »Dum- 
my-Pointer« - das ist der un- 
sichtbare Mauszeiger, der akti- 
viert wird, sobald sich der Ball 
unter einer bestimmten Posi- 
tion befindet. 

CloseW() gibt alle angefor- 
derten Speicherbereiche wie- 
der ans System zurück. In der 
Hauptfunktion main() teilen wir 
CLXCON mit, daß wir Informa- 
tionen über die Kollision mit ge- 
setzten Bits der ersten BitPlane 
wünschen. 

Diese Kollision findet statt, 
wenn unser Sprite mit einer Far- 
be des zweiten oder des vierten 
Farbregisters zusammentrifft - 
bei beiden ist das Bit der ersten 
Plane gesetzt. Wir testen dem- 
nach CLXDAT auf den Wert 4 
(29/001) - also auf Kollision des 
Sprites 2 mit einer ungeraden 
BitPlane. 


Points=0; 
XPos=20+VBeamPos() ; 
YPos=20; < 
SetRast(RP,2); 
RefreshWindowFrame (win); 
Ғог(1=0;1<10;14+)[ 

х=1%64; 

р=р?0:1; . 


) 
) 
Score(); 
} 
VOID MakeCList(y) 
SHORT y; 
( 


0; 


if(GAlert) 


CINIT(UCList,5); 
CWAIT(UCList,y-3,0); 


CWAIT(UCList,y49,0); 
CWAIT(UCList, 254,0); 


CEND(UCList) ; 
VPort->UCopIns=UCList; 
RemakeDisplay(); 

) 

VOID main() 


( 


USHORT code; 

ULONG class; 
OpenW() ; 

Init(); 
custom.clxcon=0x41; 
while(1){ 


REGISTER SHORT 1,),х,у,р-0; 


SetafPt(RP,Pattern+p,3%p) ; 


for(j=1; Jj <6;j++)[ 
y=5*40; 
Draw0(1,30+x,y,5); 
if(i<9) Draw0(3,64+x,y+20,5); 


else NewCol=0xFFO; 


SHORT x=4,y=2,collision=custom.clxdat; 


class=GetMessage(&code) ; 
if(class==CLOSEWINDOW) break; 


Weiterhin erwarten wir den 
Wert 0x200. Er wird beim Zu- 
sammentreffen des Schlägers 
mit dem Ball gesetzt (Kollision 
Sprite 0 mit Sprite 2 = CLX- 
DAT-Bit 9 = %200). Sie finden 
die Abfrage am Ende des Quell- 
codes. 

MoveSprite() bewegt den Ball 
(siehe Anfang der While-Schlei- 


fe in main()), indem zu der ak- . 


tuellen X- und Y-Position des 
Sprites ein entsprechender 
Wert addiert wird. Die Kollision 
des Spielfeldrandes überprü- 
fen wir über die Sprite-Position. 
Das x- bzw. y-Inkrement wird 
beim Zusammentreffen ne- 
giert, so scheint der Ball am 
Spielfeldrand zu reflektieren. 
Stellen Sie doch einige Ver- 
suche mit dem Programm an - 
besonders interessant (und 


auch etwas schwieriger) wird 
das Spiel nach dem Entfernen 
des MakeCList()-Aufrufs in 
main(). Am besten gleich testen 
- viel Spaß dabei! so 


NewCol=( (NewCo1+0x100) > 0xF00) ?0:NewCo1+0x10 


CMOVE(UCList,custom.color[2],NewCol); 
CMOVE(UCList,custom.color[2],01dCo1l); 


CMOVE(UCList, custom.color[1],OxF00) ; 


else  SetPointer(win,&Pointer[0],3,16,0,0) ; 
MakeCList(YPos); 
1f(XPos > =620) xe-4; 


else if(XPos< 216) 
if (YPos > =246){ 
y--2; 
Points++; 
if(Points>9){ 
SetWindowTitles(win,GOVER,-1); 
dof 
WaitPort(win->UserPort) ; 
class=GetMessage(&code) ; 
| while (KEYDOWN) ; 
SetWindowTitles (win, GNAME,-1) ; 
Init(); 
} 
else Score(); 
} 
else if(YPos<=14) y=2; 
collision=custom.clxdat; 
if((collision&0x200)==0x200) y=-2; 
else if((collision&4)==4)[ 
DrawC(2,XPos+10+x, YPos+3+y,4) ; 
ха-х; 
} 
) 
CloseW(); 
1 H 


Listing 1. Hardware-Sprites werden mittels der 
SimpleSprite-Struktur beschrieben 


#include <graphics/sprite.h> 

#include <hardware/custom.h> 

#include <exec/memory.h> 

#include <exec/types.h> 

#include <funcetions.h> 

#define KEYDOWN ((code! =SELECTUP) && (class! =CLOSEWINDOW) ) 

#define TDIM 100 

#define GNAME ((STRPTR)" -%- HotBottom -*-”) 

#define GOVER ((STRPTR)”--->> GAME-OVER < <--- 

SHORT SpriteNr=-1; 

SHORT GAlert: 

SHORT Points; 

SHORT МенСо1,014С01; 

SHORT ХРов,ҮРов; 

WORD Buffer[10]; 

UWORD *Pattern,PatternDat[9]-[ 
OxFFFF , 0x1111,0x2222, 
0х4444,0х8888,0х1111, 
0х2222,0х4444,0х8888 


(Klick...)”) 


); 
UWORD *Pointer, *Ball, *Dummy; 
UWORD PointerDat(]=[ 
0,0, ОхҒЕРЕ,0, 0,0xFFFF, OXFFFF,OXFFFF, 0,0 
); 
UWORD BallDat[]s[ 

0,0, 0х1800,0х2000,0х1000, 
0х6000,0х8С00,0хЕ200, 
0х8000,0хҒЕ00,0хС200, 
0хҒЕ00,0х7000,0х7С00, 
0х3800,0х3800, 0,0 


); 


struct 


SimpleSprite Sprite=[ 
NULL,7,10,10,2 


NewWindow nwin={ 
0,0,640,256,0,1,CLOSEWINDOWI MOUSEBUTTONS, 
WINDOWCLOSEI RMBTRAPI ACTIVATE, NULL, NULL, 
GNAME, NULL, NULL, 0,0,0,0,WBENCHSCREEN 


IntuitionBase 
struct GfxBase 
struct Screen *Screen; 
struct Window *win; 
struct RastPort *RP; 
struct ViewPort XVPort; 
struct UCopList *UCList=NULL; 


*IntuitionBase; 
*GfxBase; 


MoveSprite(VPort, &Sprite,XPos+=x,YPos+=y) ; 
if((YPos< 200) &&(Screen->MouseY>10)) 
SetPointer(win, &Dummy[0],1,1,0,0); 


struct TmpRas Raster; 
struct AreaInfo AInfo; 
PLANEPTR Bitplane; 
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/* 

\\ Funktionen 
WA 

VOID CloseW() 


( 


if(SpriteNr>=0) 
if(Pattern) 
if(Pointer) 
if(Ball) 

if(win) 
if(Bitplane) 
if(UCList){ 


FreeSprite(SpriteNr) ; 


FreeMem(Pattern, 32) ; 
FreeMem(Pointer,20) ; 
FreeMem(Ball, 36) ; 
CloseWindow(win) ; 
FreeRaster(Bitplane,TDIM,TDIM); 
FreeVPortCopLists(VPort); 


RemakeDisplay(); 


) 

1f(GfxBase) 
if(IntuitionBase) 
exit(0); 


] 


VOID OpenW() 


( 
REGISTER SHORT 1; 


CloseLibrary(GfxBase) ; 
CloseLibrary(IntuitionBase); 


if(!(IntuitionBase=(struct IntuitionBase X) 


OpenLibrary("intuition.library^,0))) 


CloseW(); 


if(! (GfxBase=(struct GfxBase *) 
OpenLibrary(”graphics.library”,0))) CloseW(); 
if(1(UCList=(struct UCopList X) 
AllocMem(sizeof(struct UCopList), 
MEMF. PUBLICI MEMF. CLEAR) ) ) 


CloseW(); 


if(!(Bitplane=AllocRaster(TDIM,TDIM))) CloseW(); 
InitTmpRas(&Raster,Bitplane,RASSIZE(TDIM, TDIM)) ; 
InitArea(&AInfo,Buffer,2); 

1f (1 (win=OpenWindow(&nwin)) ) 

RP =win->RPort; 

RP- > TmpRas =&Raster; 

RP->Arealnfo =&AInfo; 

Screen =IntuitionBase->ActiveScreen; 
VPort =&Screen->ViewPort; 
SetRGB4(VPort, 21,12,12,12); 

SetRGB4(VPort, 22,10,10,10); 

SetRGB4(VPort, 23, 8, 8, 8); 
O1dCol=GetRGB4(VPort->ColorMap,2); 


CloseW(); 


Know-How 


CopyMem(BallDat,Ball,36); 


if(!(Pattern-(UWORD *)AllocMem(32,MEMF_CHIP))) CloseW(); 
CopyMen(PatternDat,Pattern,32) ; 


Sprite.posctldata-&Ball[0]; 


SpriteNr=GetSprite(&Sprite,2) ; 


} 

ULONG GetMessage(code) 
USHORT *code; 

( 


struct IntuiMessage “msg; 
ULONG class=0; 


if(msg=(struct IntuiMessage *)GetMsg(win->UserPort) ){ 


class=msg-> Class; 
*code=msg-> Code; 
ReplyMsg(msg) ; 


return(class) ; 


VOID DrawC(col,x,y,r) 
SHORT col,x,y,r; 


SetAPen(RP,col); 
SetDrMd(RP, JAM1) ; 
AreaEllipse(RP,x,y,2*r,r); 
AreaEnd(RP); 


VOID Block(col,x1,y1,x2,y2) 
SHORT col,x1,y1,x2,y2; 
SetAPen(RP,col) ; 


SetDrMd(RP, JAM1) ; 
RectFill(RP,x1,y1,x2,y2) ; 


VOID Score() 


SHORT со1-Роіп%8>872:2, 


topz254-24XPoints; 


GAlert=-2+col; 
Block( 1,0, 10,10,256); 
Block(col,2,top, 8,254); 


1f(1(Dummys(UWORD *) 

AllocMem(10,MEMF_CHIPI MEMF. CLEAR) ) ) 
if(!(Pointer=(UWORD *)AllocMem(20,MEMF_CHIP) )) 
CopyMem(PointerDat, Pointer, 20) ; 
if(1(Ball=(UWORD %)А11осМеп(26,МЕМЕ СНІР))) 


ie Amiga-Hardware 

Stellt dem Programmie- 

rer acht Sprites zur Ver- 
fügung. Für viele Anwendun- 
gen, besonders für Spiele, 
reicht das nicht aus, zumal das 
erste Sprite auch noch für die 
Darstellung des Mauszeigers 
reserviert ist. Abhilfe schafft die 
Verwendung der sogenannten 
virtuellen Sprites (»VSprites«), 
die sich auf dem Display gleich 
mehrfach darstellen lassen. 

Im Grunde genommen sind 
virtuelle (scheinbare) Sprites, 
kurz VSprites genannt, einfach 
Hardware-Sprites, die im Dis- 
play durch die Mehrfachver- 


| Listing 2. Spiele 
Closew(); sind die Haupt- 


CloseW(); 


anwendungs- 
( gebiete für Sprites 


VOID Init() 


CloseW(); 


Alle VSprites können in Form 
und Farbe völlig frei gestaltet 
werden. Je nach Aufwand fal- 
len daher eine Menge Daten 
an. Glücklicherweise über- 
nimmt deren Verwaltung das 
Grafiksystem für uns, so daß 
uns nur noch die Arbeit der Ini- 
tialisierung einiger Datenstruk- 
turen bleibt. 

Für Hardware-Sprites ist, ne- 
ben der Festlegung der Image- 
Daten, lediglich die Vereinba- 
rung der kurzen SimpleSprite- 
Struktur nötig. Um virtuelle Spri- 
tes verwalten zu können, erwar- 
tet das System die Belegung 
zweier Strukturen: die GELsIn- 


»Graphic Elements« - Teil 1: VSprites 


prite 


Was tun, wenn die 
acht Amiga-Sprites 
nicht ausreichen? 
Wir bauen unsere 
eigenen mit Hilfe 
eines kleinen Tricks: 
Wir verwenden 
virtuelle Sprites. 


irtue 


Von Arno Gölzer 


wendung der Spritekanäle »ge- 
multiplext« werden können. Da- 
her gelten die meisten der Re- 
geln für die Programmierung 
der Hardware-Sprites (siehe 
Seite 53) auch für VSprites. 
Der wichtigste Unterschied 
ist der Wegfall der Beschrän- 
kung auf die Gesamtzahl von 
acht. Eine maximale Anzahl ist 
nicht vorgeschrieben, sie ist 
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vom Anwendungsfall abhän- 
gig. Vor dem ersten Einsatz der 
VSprites müssen wir dem Sy- 
stem mitteilen, welche der acht 
Hardware-Sprites dafür abge- 
zweigt werden sollen. Diese 
werden - soweit sie noch frei 
sind - als belegt gekennzeich- 
net und für die Darstellung der 
VSprites abgezweigt. 


Mehrere VSprites, die auf 
dem gleichen Hardware-Sprite 
basieren, lassen sich nicht di- 
rekt nebeneinander darstellen. 
Die beiden Bilder müssen min- 
destens durch eine Rasterzeile 
getrennt sein. Bei Nichtbeach- 
tung dieser Regel, ist nur der 
VSprite mit der kleineren X- 
Position sichtbar. 


fo- und die VSprite-Struktur. 
Die erste der beiden verwal- 
tet eine Reihe von Grafik-Ele- 
menten (Graphic Elements = 
GELs), die, ähnlich den Area- 
Objekten, durch Aufruf eines 
einzigen Befehls auf den Bild- 
schirm gebracht werden. Außer 
den VSprites kennt das System 
die Grafik-Elemente BObs, 
AnimComps und AnimObjects. 
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Welche Werte müssen wir in 
GELsinfo (Listing 1) für VSprites 
belegen? Die erste Komponen- 
te, ein Byte namens »sprRsrvd«, 
beinhaltet die Information, wel- 
che Hardware-Sprites vom Sy- 
stem für die Verwendung der 
VSprites verlangt werden: 


Sprite-Reserved-Bii 


sprRsrvd Bit: 7 6 5 4 
Sprite-Nr.: 54321 


Für jedes gewünschte Sprite 
müssen wir in sprRsrvd das der 
Spritenummer Коггеѕропаіе- 
rende Bit setzen. Móchten wir 
beispielsweise für die Dar- 
stellung unserer VSprites die 
Hardware-Sprites mit den 
Nummern 6 und 7 einsetzen, 
setzen wir die Bits 6 und 7 und 
setzen als sprRsrvd-Wert 
%11000000 = 192 ein. 

Die nächste Variable »Flags« 
wird ausschließlich vom Sy- 
stem genutzt. Wie oben er- 
wáhnt, verwaltet die GELsInfo- 
Struktur eine Kette von GELs. 
Das Struktur-Element »GEL- 
Head« erwartet die Adresse des 
Kopfes, also die der ersten 
Struktur und »GELTail« die der 
letzten Struktur der GELs-Kette. 
Es handelt sich hierbei lediglich 
um Dummy-Strukturen, die kei- 
ne Daten eines Grafik-Elements 
enthalten sollten. 

Die beiden náchsten Para- 
meter, nextLine und lastColor, 
sind wieder nur für das System 
bestimmt, jedoch müssen wir 
für den notwendigen Speicher- 
platz sorgen (siehe GetGELsIn- 
fo() in Listing 3). Es folgt die 
Adresse auf die in graphics/ 
gels.h definierte ` collTable- 
Struktur. Es handelt sich hierbei 
um ein Array mit 16 Funktions- 
Adressen, die nach Kollisionen 
von Grafik-Elementen aufgeru- 
fen werden. Die Kollisionskon- 
trolle stellt ein weiteres Bonbon 
der VSprite-Verwaltung dar. 
Das System nimmt uns die 
Uberwachung der VSprites ab. 

Welche Funktionen bei wel- 
chen Kollisionen gestartet wer- 
den, legen wir mittels zweier 
Masken innerhalb der VSprite- 
Struktur fest - hierzu lesen Sie 
spater mehr. 

Die folgenden. vier WORD- 
Variablen stellen die Grenzen 
fur die Elemente der GELs- 
Kette dieser GELsInfo-Struktur 
dar. Uberschreitet ein VSprite 
diese Grenze, wird, wenn ge- 
wünscht, die Kollisionsrouti- 
ne[0] aus dem collTable-Array 
aufgerufen. Die beiden letzten 
GELsInfo-Werte sind wiederum 
System-Variablen. 
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Die immer wieder nach dem 
gleichen Modus ablaufende Ini- 
tialisierung der GELsInfo-Struk- 
tur schreit förmlich nach einer 
Automatisierung. Daher stellen 
wir Ihnen in unserem GELTool.h 
(Listing 3) Routinen zur Verfü- 
gung, die Ihnen unter anderem 
die Initialisierungsarbeit und 
auch das Freigeben дег GELs- 
Info-Struktur abnehmen. 

Die Funktion GetGELsInfo(& 
RastPort,sprRsrvd,Im,tm,rm, 
bm) verlangt als Parameter (von 
links nach rechts) die Adresse 
des Display-RastPorts, das 
sprRsrvd-Byte, wie oben be- 
sprochen, und dann die Gren- 
zen der GELs-Kette in der Rei- 
henfolge linker Rand, oberer 
Rand, rechter Rand und unte- 

rer Rand. 

Die Funktion liefert die Adres- 
se der fertig initialisierten GELs- 
Info-Strukur oder, im Fehlerfal- 
le, den Wert NULL. 


struct GGELsInfo GI; 


GI-GetGELsInfo(R,s,1,t, 
r,b); 


Das Gegenstück zu GetGELs- 
Info() stellt die Funktion Free- 
GELsInfo(GELsInfo) dar. Sie er- 
wartet als Parameter den Rück- 
gabewert der GetGELsinfo()- 
Funktion. Ihre Aufgabe ist die 
Freigabe des durch die GELsIn- 
fo-Struktur belegten Speichers. 
Die Voraussetzungen für die 
Verwendung von VSprites sind 
jedoch erst mit der Vereinba- 
rung der VSprite-Struktur (Li- 
sting 2) abgeschlossen. Diese 
Struktur ist, von der Bedeutung 
her, etwa mit der SimpleSprite- 
Struktur der Hardware-Sprites 
vergleichbar. Sie ist jedoch sehr 
viel umfangreicher. Bei der Be- 
sprechung dieser Struktur wer- 
den die Besonderheiten der 
VSprites besonders deutlich. 


Werkzeuge zur 
Initialisierung 


Beachten Sie, daß diese Struk- 
tur auch bei der Verwendung 
von BObs (Blitter Objects) von 
groBem Interesse ist. Wir be- 
sprechen sie an dieser Stelle je- 
doch gezielt für VSprites. 
NextVSprite ist das náchste 
VSprite (oder ein mittels der 
VSprite-Struktur spezifiziertes 
Grafikelement) in einer Liste 
von Grafikelementen. PrevV- 
Sprite ist das vorhergehende 
VSprite in dieser Liste. Die Va- 
riablen NextSprite und Prev- 


Sprite verwaltet das Grafiksy- 
stem selbst. 

DrawPath, ClearPath, OldY, 
OldX interessieren uns im Mo- 
ment weniger, sie sind nur beim 
Programmieren von  BOb's 
wichtig. Flags: Das Setzen des 
Flags VSPRITES kündigt die 
Arbeit mit VSprites an. 

Setzt das System das Flag 
VSOVERFLOW, so konnte das 
Display, wegen der Verwen- 
dung zu vieler VSprites (an ei- 
ner Position), nicht korrekt auf- 
gebaut werden. Bei unserem 
Beispielprogramm »VS« (LL 
sting 4) láBt sich das gut beob- 
achten. Befinden sich viele 
VSprites in einer Zeile, so wird 
ein Teil davon einfach nicht 
dargestellt Mindestens zwei 
VSprites in einer Zeile liegen 
dann dem gleichen Hardware- 
Sprite zugrunde. Zur korrekten 
Darstellung sollten sie, wie 
schon angedeutet, mindestens 
durch eine Rasterzeile getrennt 
sein. Das Flag GELGONE deu- 
tet darauf hin, daB sich wenig- 
stens ein Grafik-Element außer- 
halb der in der GELsInfo-Struk- 
tur angegebenen Grenzen be- 
findet. 

Y, X ist die Position des VSpri- 
tes. Height ist die Hóhe des 
VSprites in Pixeln gemessen. 
Width ist die Breite des VSpri- 
tes in WORDs. Da alle Sprites 
immer 16 Pixel, also ein WORD, 
breit sind, muB hier der Wert 1 
eingetragen werden. Diese und 
auch die nachste Variable ist 
bei der Verwaltung der BObs in- 
teressanter. Depth ist die An- 
zahl der BitPlanes, für VSprites 
kommt nur der Wert 2 in Frage, 
bei BObs sieht das etwas an- 
ders aus (siehe Seite 62). 

MeMask, HitMask: Diese bei- 
den Variablen sind für die Kolli- 
sionserkennung von größter 
Bedeutung. Weiter oben haben 
wir bereits angesprochen, daß 
das System die Kollisionsabfra- 
ge zwischen Grafik-Elementen 
für uns übernimmt. Alle GELs 
einer Kette kónnen in die Abfra- 
ge einbezogen werden. Welche 
GELs womit kollidieren, legen 
wir mit den »Hit-Me«-Masken 
fest. 5, 

Möglich ist die Überwachung 
der Kollisionen GEL/GEL und 
GEL/Border. Der einfachste Fall 
ist sicher die Festlegung der 
Kontrolle über die Randkolli- 
Sion. Setzen wir Bit O der Hit- 
Maske des zu kontrollierenden 
GELs mit dem Wert 


%0000000000000001. 
so wird die Funktion mit der 
Adresse an Position 0 des 


Funktions-Arrays ` »collTable« 
der GELsInfo-Struktur aufgeru- 


fen, wenn sich das Grafik-Ele- 
ment an den, in der gleichen 
Struktur festgelegten, Grenzen 
befindet. Welche Funktion das 
ist, legen wir vor der Vereinba- 
rung der VSprite-Struktur mit- 
tels der Funktion 


SetCollision(0,CheckBor- 
der, &GELsInfo) ; 


fest. SetCollision() schreibt die 
Adresse der selbstdefinierten 
Funktion CheckBorder() an die 
Position 0 der Funktionstabelle 
»collTable« der GELsinfo-Struk- 
tur, deren Adresse als dritter Pa- 
rameter angegeben ist. 


GELs auf 
Kollisionskurs 


Rufen wir jetzt die Funktion 
DoCollision(&rp) auf, als Para- 
meter dient die Adresse des 
RastPorts, wird, falls eine Kolli- 
sion festgestellt wurde, nach 
CheckBorder() : verzweigt. Als 
Parameter werden dabei die 
Adresse der VSprite-Struktur 
des GELs und ein Flag-Byte 
übergeben: 


VOID CheckBorder(vs, 
flag) 
struct VSprite xvs; 
BYTE flag; 


| 
ү» 


Der Byte-Wert übermittelt 
uns, an welcher Grenze das 
GEL kollidiert ist. Es bedeuten 
die Symbole LEFTHIT - linker 
Rand; TOPHIT - oberer Rand; 
RIGHTHIT - rechter Rand; 
BOTTOMHIT - unterer Rand, 
Da bei einem Aufruf, z.B. bei 
der Kollision mit der linken obe- 
ren Ecke, mehrere Werte, für 
das Beispiel LEFTHIT und TOP- 
HIT, gesetzt sein kónnten, ist 
das betreffende Flag durch eine 
AND-Verknüpfung zu erfragen. 
Zum Beispiel für den oberen 
Rand: 


if((flag&TOPHIT) == 
TOPHIT)( 


) 


Bei Kollisionen zwischen 
GELs (GEL/GEL) können die 
Funktionen der zweiten bis 
fünfzehnten Adresse der Funk- 
tionstabelle in GELsInfo aufge- 
rufen werden. Welche, ent- 
Scheidet die Bitbelegung der 
AND-Verknüpfung der Hit-Mas- 
ke des einen GELs mit der Me- 
Maske eines anderen GELs. 
Ein Beispiel verdeutlicht den 
Sachverhalt: Angenommen, 
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wir arbeiten mit zwei bewegten 
VSprites. Bei einer Kollision soll 
die selbstdefinierte Funktion 
CheckColl() aufgerufen wer- 
den. Erster Schritt - die SetCol- 
lision()-Funktion aufrufen: 


SetCollision(1,Check 
Coll,GELsInfo); 


Die Adresse der CheckColl()- 
Funktion wird dadurch in collTa- 
ble an der zweiten Stelle einge- 
tragen - die erste Stelle bele- 
gen wir mit SetCollision(0,...). 

Zweiter Schritt - VSprite- 
Struktur initialisieren. Dabei 
setzen wir beide Me-Masken 
und beide Hit-Masken der 
GELs gleich 


%0000000000000010 


Das zweite Bit ist gesetzt, da- 
her wird auch bei einer Kollision 
die zweite Funktion der Kolli- 
sionstabelle aufgerufen, und 
das ist in unserem Beispiel 
CheckColl(). 

Ob eine Kollision stattfand, 
ermittelt - wie im ersten Bei- 
spiel - DoCollision(). In diesem 
Fall werden unserer Funktion 
jedoch, anstelle einer VSprite- 
Strukturadresse und einem 


Flag, zwei VSprite-Struktur- 
adressen, nämlich die der bei- 
den | zusammengestoBenen 


VSprites, übergeben: 
VOID CheckColl(vsi,vs2) 
struct VSpritexvs1,xvs2; 


| 
E 


Die erste Adresse stammt 
von dem VSprite, welches sich 
bei der Kollision links und/oder 
oberhalb des anderen befand. 
Die BitNummer des Ergebnis- 
ses der AND-Verknüpfung der 
Me-Maske des einen, mit der 
Hit-Maske des anderen GELs 
bestimmt also die Funktion, die 
bei einer Kollision aufgerufen 
werden soll. Sind im Ergebnis 
mehrere Bits gesetzt, entschei- 
det das niederwertigste Bit über 
den Aufruf: 


%0000101011000010 


In diesem Beispiel würde Do- 
Collision() bei einer »passen- 
den« Kollision die zweite Funk- 
tion der Tabelle aufrufen. Vor- 
aussetzung für die erfolgreiche 
Überwachung ist die Berech- 

«nung der sogenannten Border- 
line und der CollMask (siehe 
unten). 

Weiterhin muß erwähnt wer- 
den, daß DoCollision() manch- 
mal Kollisionen »übersieht«, be- 
sonders wenn Sie viele VSpri- 
tes verwenden und nur wenige 
Hardware-Sprites einsetzen. In 
diesen Fällen sollte man auch 


AMIGA-SONDERHEFT 7 


die Kollisionsroutine besonders 
kurz halten (siehe Demo Listing 
4). ImageData ist die Adresse 
des UWORD-Arrays, welches 
die Daten für den Sprite enthält. 
Die Daten werden wie »norma- 
le« Sprite-Daten ermittelt, je- 
doch fallen bei VSprites die bei- 
den 0-UWORDS vor und nach 
der Sprite-Beschreibung weg. 
Das Array muß im Chip-Memo- 
ry liegen, VSprites mit gleichem 
Aussehen dürfen hier, anders 
als bei Hardware-Sprites, auf 
das gleiche Array zurückgrei- 
fen. 

BorderLine: der Wert dieser 
VSprite-Strukturkomponente 
ist für die Kollisionserkennung 
nótig. Ein VSprite darf mehrere 
Zeilen hoch sein. Eine Sprite- 
zeile wird mit 2 UWORDs be- 
schrieben. Der Wert Borderline 
ist das Ergebnis der ODER- 
Verknüpfung aller WORDs und 
ist daher genau ein WORD breit 

(siehe auch unter CollMask). 


Ganz ohne 
Bitpfriemelei 


CollMask (siehe auch »Bor- 
derLine«). CollMask enthált die 
ODER-Verknüpfung der beiden 
VSprite-Planes. Es handelt sich 
demnach um ein WORD-Array, 
dessen Elementezahl von der 
Hóhe des VSprite abhángt. Be- 
vor Sie sich Sorgen um die Be- 
rechnung der Werte BorderLine 
und CollMask machen, sei er- 
wähnt, daß bereits eine Funk- 
tion eingerichtet wurde, die uns 
dieses Übel abnimmt: 


InitMasks(&VSprite); 


Die InitMasks()-Funktion, mit 
der Adresse der entsprechen- 
den VSprite-Struktur als Para- 
meter, Ubernimmt die Berech- 
nung für uns. 

SprColors ist die Adresse ei- 
nes UWORD-Arrays, welches 
aus drei Werten besteht. Hier 
befinden sich die VSprite-Far- 
ben, die wie gewohnt als 16-Bit 
Wert (wovon allerdings bisher 
nur die unteren 12 genutzt wer- 
den), angegeben wird. Zum 
Beispiel für weiß: OXFFF. Jedes 
VSprite kann über eine eigene 
Farbenpalette verfügen oder 
auch die eines anderen mitbe- 
nutzen. 

VSBOb enthált die Adresse 
einer Bob-Struktur, die jedoch, 
wenn das VSPRITE-Flag ge- 
setzt ist, ignoriert wird. Plane- 
Pick, PlaneOnOff: Diese Wer- 
te sind nur bei der Verwendung 
von BObs nótig. VUserExt für 
das Einbinden eigener Werte 
oder Strukturen in die VSprite- 
Struktur. Die Vereinbarung des 
VUserStuff-Symbols muB vor 
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das Einbinden des Headerfiles 
»graphics/gels.h« gelegt wer- 
den, sonst wird das Symbol als 
Amigadatentyp SHORT festge- 
legt. Móchte man keine Struk- 
tur, die z.B. Daten wie Ge- 
schwindigkeit oder weitere 
Image-Daten enthalten könnte, 
definieren, läßt sich VUserStuff 
als Kennummer (ID) für VSpri- 
tes verwenden (siehe Beispiel- 
listing 4). 

Auch für die Initialisierung 
der VSprite-Struktur haben wir 
eine Hilfsfunktion erstellt: 


struct VSprite xVS; 


VS=GetVSprite(&rp,x,y,h, 
me,hi,d,c,u); 


GetVSprite() füllt die VSprite- 
Struktur mit Werten auf. Die Pa- 
rameter (von links nach rechts) 
sind: die Adresse des Display- 
RastPorts; die X/Y-Position des 
VSprites (bezogen auf die linke 
obere Ecke des ViewPorts oder 
Screens), die Höhe des VSpri- 
tes; MeMask und HiMask; die 
Adresse der Image-Daten; die 
Adresse des Color-Arrays und 
die VUserExt-Variable. Die 
Funktion liefert die Adresse der 
fertig initialisierten VSprite- 
Struktur oder, falls ein Fehler 
auftrat, den Wert NULL. 

GetVSprite ruft die »Univer- 
sal-Funktion« GetGel() auf, wel- 
che neben VSprites auch BObs 
initialisieren kann. Wir werden 
uns im Artikel über BOBs auf 
Seite 62 näher mit ihr bescháfti- 
gen. 

Die Freigabe der VSprite- 
Struktur übernimmt das Makro 


FreeVSprite(vsp,rp,vp, 
kill); 


Die Parameter von links nach 
rechts sind: die Adresse der 
mittels GetVSprite() ermittelten 
VSprite-Struktur; die Adresse 
des RastPorts; die Adresse des 
ViewPorts und das Kill-Flag. Ist 
»Kill« ungleich null, baut die 
Funktion das Display, ohne den 
genannten VSprite, neu auf. 

Möchte man in einer Schleife 
mehrere VSprites freigeben, ist 
das Setzen des Kill-Flags erst 
beim letzten Aufruf nötig. 


for(i=0;i<n;it++){ 
FreeVSprite(vp[i],rp,vp, 
i==(n-1)); 


Nachdem wir nun die Schrit- 
te a) Initialisierung der Gelsinfo- 
Struktur; b) Festlegung der Kolli- 
sionsroutinen mit SetCollision(); 


und o) Initialisierung der VSprite- 
Struktur erledigt haben, ist es 
ап der Zeit den VSprite darstel- 
len zu lassen. Zum ersten muß 
die GELs-Liste nach den Y-Po- 
sitionen sortiert werden, Sort- 
GList(rp) erledigt das für uns, 
wenn wir die Adresse des Dis- 
play-RastPorts angeben. Als 
náchstes erzeugt DrawGList(rp, 
vp) die für die Darstellung not- 
wendigen Copperlisten. Die Pa- 
rameter sind die Adresse des 
RastPorts und die des View- 
Ports. Als letztes sorgt beim ein- 
fachen Grafikdisplay die Se- 
quenz MakeVPort(, MrgCop() 
und LoadView() (siehe hierzu 
Artikel »Display« in diesem 
Heft) dafür, daß die GELs-Kette 
endlich sichtbar wird. Intuition- 
Anwender haben es, wie so oft, 
etwas einfacher: RemakeDis- 
play() läßt die Grafik-Elemente 
erscheinen. 

Das Makro DrawGels(rp,vp), 
welches in unserem Headerfile 
definiert ist, vereinfacht die Vor- 
gehensweise. Der Aufruf, er 
verlangt die Adresse des Rast- 


Alle auf 
einen Schlag 


Ports und die des ViewPorts, 
stellt die GELs-Kette »auf einen 
Schlag« dar. Die letzte VSprite- 
Funktion (eigentlich auch ein 
Makro) unseres Tools ist Move- 
VSprite(vsp,rpvp,xy). Mit die- 
sem Hilfsmittel kann ein einzel- 
ner VSprite bewegt werden. Die 
Parameter sind: die Adresse 
des betreffenden VSprites, die 
des RastPorts und des View- 
Ports und die Inkremente x und 
y. Diese werden beim Aufruf zu 
der aktuellen VSprite-Position 
addiert. 

Mit allen Hilfsmitteln ausge- 
rüstet kann jetzt endlich die Tat 
folgen. In unserem Demo-Listing 
»VS« (Listing 4) verlangen wir 
die Darstellung von 20 (!) VSpri- 
tes in einem Display. Alle Spri- 
tes greifen auf die gleichen 
Image-Daten zurück, jedoch 
werden sie mittels fünf ver- 
schiedener Farbenpaletten (5 x 
3 = 15 Farben) auf dem Work- 
benchscreen dargestellt. Je- 
weils vier VSprites erscheinen 
also in der gleichen Farbe. Da 
wir als sprRsvd-Wert OxFE an- 
gegeben haben, wird auch 
Sprite 1, das mit Sprite 0 (dem 
Pointer) ein Sprite-Paar bildet, 
in die Darstellung mit einbezo- 
gen. Da jeweils ein Sprite-Paar 
über ein gemeinsames Farbre- 
gister verfügt, nimmt der Maus- 
zeiger stándig die Farbe seines 
»Partners« an. In OpenW() le- 
gen wir fest, daß im Falle einer 
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Randkollision die Funktion Bor- 
Con() starten soll. Dort negieren 
wir den Geschwindigkeits-Vek- 
tor, der für die Kollision veran- 
twortlich war. Weiterhin sollen 
bei GEL/GEL Kollisionen, die 
als Ergebnis der AND-Verknüp- 
fung der Hit/Me-Masken die 
Bits 1-5 setzen, die Funktion 
MarCon() aufgerufen werden. 
In der darauffolgenden Schleife 
legen wir die Hit/Me-Masken in 
Abhángigkeit des Farbwertes 
fest. Kollisionen unter gleichfar- 
bigen VSprites rufen über Do- 
Collision) die Funktion Mar- 
Con() auf. Diese haben wir, we- 
gen Unterscheidung über 
Kennummer der hohen VSprite- 
Anzahl extrem kurz gehalten - 
wir ermitteln nur die VSprites- 
IDs. Diese Kennummern legen 
wir ebenfalls in der zweiten 
FOR-Schleife der OpenW()- 
Funktion fest. 

Der Aufruf des Makros Draw- 
Gels() macht die Grafik-Ele- 
mente sichtbar. In einer Endlos- 
Schleife innerhalb der main()- 
Funktion bewegen wir alle 
VSprites, indem wir den X/Y- 
Positionen die entsprechenden 
Werte aus den Arrays vX[] und 
УҮ[] addieren und danach das 
Display mittels DrawGels() neu 
darstellen lassen. Natürlich 
kónnten wir hier auch MoveV- 
Sprite() einsetzen. Jedoch wür- 
de die Funktion nach der Verán- 


struct GelsInfo 

[ 
BYTE sprRsrvd; 
UBYTE Flags; 


derung jedes Sprites das Dis- 
play neu berechnen. Diese 
Funktion eignet sich besser für 
die Bewegung eines einzelnen 
VSprites. Der Aufruf von DoCol- 
lision() nach jeder Neudarstel- 
lung des Displays kontrolliert 
die VSprites. Stellte die Funk- 
tion eine Kollision fest, ruft sie 
MarCon() auf, welche die Kenn- 
nummern der beteiligten VSpri- 
tes ermittelt. 

Nach einem Bildschirmblitz 
entfernen wir einen davon und 
die Schleife beginnt mit einem 
neuen Durchlauf. Die Funktion 
CloseW() gibt vor Programmen. 
de alle angeforderten Speicher- 
plátze wieder an das System 
zurück. Mit diesem Demo-Li- 
Sting lassen sich sehr viele Ex- 
perimente anstellen. Wie ver- 
hált sich z.B. das Programm, 
wenn 40 VSprites verlangt wer- 
den. 

Lassen sich alle VSprites in 
unterschiedlichen Farben dar- 
Stellen? Oder: was passiert, 
wenn Sie als sprRsvd einen 
kleineren Wert angeben und 
was geschieht nach der Anga- 
be von OxFF? 

Testen Sie das Programm - 
verándern Sie einfach alle Pa- 
rameter, die Ihnen nicht 
100prozentig klar sind und Sie 
werden sich offenstehende Fra- 
gen bald selbst beantworten. 

so 


struct VSprite *gelHead, *gelTail; 


WORD *nextLine; 
WORD **lastColor; 


struct collTable *collHandler; 

short leftmost, rightmost, topmost, bottommost; 

АРТЕ firstBlissObj,lastBlissObj; 
); 
Listing 1. Die Struktur GelsInfo informiert über Grafik- 
Elemente 


struct VSprite 


( 


struct VSprite *NextVSprite; 
struct VSprite XPrevVSprite; 
struct VSprite *DrawPath; 
struct VSprite *ClearPath; 
WORD O1dY, 014Х; 

WORD Flags; 

WORD Y, X; 

WORD Height; 

WORD Width; 

WORD Depth; 

WORD MeMask; 

WORD HitMask; 

WORD *ImageData; 

WORD *BorderLine; 

WORD *CollMask; 

WORD XSprColors; 

struct Bob *VSBob; 

BYTE PlanePick; 

BYTE PlaneOnOff; 

VUserStuff VUserExt; 


Listing 2. Die 
VSprite-Struktur 
beschreibt 
neben VSprites 
auch BObs- 


Gölzy's > GE1Tool.h « 
einfache Handhabung 
der Grafikelemente 


#define DrawGels(rp, vp) 
,0) 
#define MoveVSprite(vsp,rp,vp,x,y) 
#define MoveBob(bob,rp,vp,x,y) 
тізе,гр,ур,х,у) 
#define GetVSprite(rp,x,y,h,me,hi,d,c,u) GetGel(rp,VSPRITE,0,x,y,1, 
h,2,me,hi,d,c,0,0,FALSE,u,0) 
#define FreeVSprite(vsp,rp,vp,kill) 
#define FreeBob(bob,rp,vp,kill) 
rite, rp,vp,kil1) 
VOID MoveGel(vsp,rp,vp,x,y) 

struct VSprite *vsp; 

struct RastPort *rp; 

struct ViewPort *vp; 

WORD х,у; 


MoveGel(NULL,rp,vp,O 


MoveGel(vsp,rp,vp,x,y) 
MoveGel(bob->BobVSp- 


FreeGel(vsp,rp,vp,ki11) 
FreeGel(bob->BobVSp- 


if(vsp){ 
vsp->X+=x; 
vsp-> Ү+=у; 


SortGList(rp) ; 
DrawGList(rp, vp) ; 
RemakeDisplay() ; 


VOID FreeGel(vsp,rp,vp,kill) 
4 struct VSprite *vsp; 


struct RastPort *rp; 
struct ViewPort Жүр; 


SHORT kill; 


struct DBufPacket *Dp; 
struct Bob *b; 
WORD *b1,*om,*sb,*db, f,w,h,d,n=0; 
BYTE 1,m,pp,po; 
if(vsp)[ 
=vsp->Flags; 
=vsp-> Width; 
=vsp->Height; 
=vsp-> Depth; 
bl=vsp->BorderLine; 
cm=vsp- > CollMask; 
b -увр- > VSBob; 
if ( (£&VSPRITE) --VSPRITE)RenVSprite(vsp); 
else if(b) RemBob(b) ; 
if(kill)DrawGels(rp, vp); 
if(bl) FreeMem(b1,wsizeof(WORD)); 
АҒ(сп) FreeRaster(cm, (SHORT) (16*w) , (SHORT)h) ; 
Ba 
рр-уәр- PlanePick; 
pozsvsp- > PlaneOnOff; 
mepo&lpp; 
for(1-0;1«8;14«) if(n&(1« <1)) ne; 
sb=b->SaveBuffer; 
Dp=b->DBuffer; 
if(sb) FreeRaster(sb, (SHORT) (16*w) , (SHORT) ( 
(d+n)*h)); 
if(Dp)[ 
db=Dp- > BufBuffer; 
if(db) FreeRaster(db, (SHORT) (16%и), 
(SHORT) ( (d+n)*h)); 
FreeMem(Dp,sizeof(struct DBufPacket) 
% 
Dp=NULL; 
) 
FreeMem(b,sizeof(struct Bob)); 
] 
FreeMen(vsp,sizeof(struct VSprite)); 
) 
) 
struct VSprite *GetGel(rp,f,bf,x,y,w,h,d,me,hi,da,c,pp,po, dbuf, vu, bu) 
struct RastPort *rp; 
BOOL dbuf; 
WORD f,bf,x,y,w,h,d,me,hi,*da,*c; 
BYTE pp,po; 
VUserStuff vu; 
BUserStuff bu; 
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10)))[ 


struct VSprite *VSprite; 
struct Bob *Bob; 
struct DBufPacket *Dp=NULL; 
WORD *b1=NULL, *cm=NULL, *db=NULL, *sb=NULL,n=0; 
BYTE i,m=po&! pp; 
if(!(VSprite=(struct VSprite X) 
AllocMem(sizeof(struct VSprite),MEMF. CLEARI MEMF_PUBL- 


return(NULL) ; 
) 
VSprite->Flags 
VSprite->X 
VSprite->Y 
VSprite->Width 
VSprite->Height 
VSprite-> Depth 
VSprite->MeMask 
VSprite->HitMask = hi; 
VSprite-> ImageData = da; 
if(!(bl=(WORD *)AllocMem(w*sizeof (WORD) ,MEMF_CLEARI MEMF. PUBL- 


return(NULL) ; 

} 

VSprite->BorderLine = 01; 

if(!(em=(WORD *)AllocRaster( (SHORT) (16%w) , (SHORT)n)))[ 
return(NULL) ; 

] 


VSprite->CollMask сп; 
VSprite->SprColors (£&VSPRITE) ==VSPRITE?c: NULL; 
VSprite->PlanePick = pp; 
VSprite->PlaneOnoff po; 
VSprite->VUserExt = vu; 
InitMasks(VSprite) ; 
if ((£&VSPRITE) !=VSPRITE)[ 
for(1=0;1<8;i++) if(n&(1« «1)) nee; 
if(!(Bob=(struct Bob #) 
AllocMem(sizeof(struct Bob) ,MEMF_CLEARI MEMF_ 


PUBLIC) ) ){ 


return (NULL) ; 
} 
VSprite->VSBob 
Bob->Flags = bf; 
if ( (£&SAVEBACK) ==SAVEBACK) { 

if(!(sb=(WORD ж) AllocRaster( (SHORT) (16%ы) , (5- 


= Bob; 


HORT) ((d+n)*h) ))){ 


EMF. CLEARI MEMF_PUBLIC) ) ) 


HORT) ((d4n)*h)))){ 


) 


return(NULL) ; 


22% 
Bob->SaveBuffer = sb; 

Bob- > ImageShadows VSprite->CollMask; 
Bob- > BobVSprite = VSprite; 
if(dbuf) 
if(!(Dp=(struct DBufPacket *) 
AllocMem(sizeof(struct DBufPacket),M 


return(NULL); 
4f(1(db=(WORD X)AllocRaster((SHORT)(16Xw),(S- 


return(NULL) ; 


] 

Dp->BufBuffer = db; 
Bob->DBuffer Dp; 
Bob->BUserExt = bu; 


] 
if((£&VSPRITE)==VSPRITE)AddVSprite(VSprite,rp); 


else 
return(VSprite) ; 


AddBob (Bob, rp); 


struct Bob *GetBob(rp,f,bf,x,y,W,h,d,me,hi,da,pp,po,dbuf, vu, bu) 


struct RastPort *rp; 

BOOL dbuf; 

WORD f,bf,x,y,w,h,d,me,hi, да; 
BYTE pp,po; 

VUserStuff vu; 

BUserStuff bu; 


struct VSprite *VSprite; 
f&= VSPRITE; 
if(VSprite=GetGel(rp,f,bf,x,y,w,h,d,me,hi,da,NULL,pp,po, dbuf- 


} 


Know-How 


return(VSprite-> VSBob) ; 


else  return(NULL); 


VOID FreeGelsInfo(GelsInfo) 


І 


) 


struct GelsInfo *GelsInfo; 


struct collTable %с%; 

struct VSprite *he,*ta; 

WORD *n1,**1c; 

if(GelsInfo){ 
he=GelsInfo- > gelHead; 
ta=GelsInfo->gelTail; 
nl=GelsInfo->nextLine; 
1e=GelsInfo->lastColor; 
et=GelsInfo->collHandler; 
if(he) FreeMem(he,sizeof(struct VSprite)); 
if(ta) FreeMem(ta,sizeof(struct VSprite)); 
if(nl) FreeMem(n1,8*sizeof(WORD)); 
if(1e) FreeMen(1e,8*sizeof(LONG)); 
if(ct) FreeMem(ct,sizeof(struct collTable)); 
FreeMem(GelsInfo,sizeof(struct GelsInfo)); 

] 


struct GelsInfo *GetGelsInfo(rp,sr,1m,tm,rm,bm) 


LIC))){ 


Ic))){ 


10))){ 


LIC))){ 


BLIC))){ 


struct RastPort *rp; 
BYTE sr; 
SHORT 1m,tm,rm,bm; 


struct GelsInfo *GelsInfo; 
struct VSprite *Head,*Tail; 
struct collTable *ct; 
WORD *n1,**1e; 
if(!(GelsInfos(struct GelsInfo *) 
AllocMem(sizeof(struct GelsInfo) ,MEMF_CLEARI MEMF_PUB- 


return(NULL) ; 


if(!(Head=(struct VSprite *) 
AllocMem(sizeof(struct VSprite) ‚MEMF_CLEARI MEMF_PUBL- 


FreeGelsInfo(GelsInfo); 
return(NULL) ; 


if(1(Tail=(struct VSprite *) 
AllocMem(sizeof(struct VSprite) ,MEMF_CLEARI MEMF_PUBL- 


FreeGelsInfo(GelsInfo); 
return(NULL) ; 


if(!(n1=(WORD *)AllocMem(8*sizeof (WORD) , MEMF_CLEARI MEMF. PUBL- 


FreeGelsInfo(GelsInfo); 
return(NULL) ; 


if(1 (1e s (WORD **)AllocMem(8*sizeof (LONG) , MEMF. CLEAR MEMF. PUB- 


FreeGelsInfo(GelsInfo); 
return(NULL) ; 


if(!(et=(struct collTable X) 
AllocMem(sizeof(struct collTable),MEMF. CLEARI MEMF_PU- 


FreeGelsInfo(GelsInfo); 
return(NULL); 


GelsInfo-»sprRsrvd =8г; 
GelsInfo->nextLine snl; 


GelsInfo->lastColor =lc; 
GelsInfo->collHandler =ct; 
GelsInfo-> leftmost =lm; 
GelsInfo->rightmost =rm; 
GelsInfo-> topmost =tm; 
GelsInfo->bottommost =bm; 
InitGels(Head,Tail,GelsInfo); 
rp->GelsInfo =GelsInfo; 
return(GelsInfo); 


Listing 3. Unser Headerfile GELTool.h unterstützt Sie 


‚vu,bu)) 


beim Arbeiten mit beweglichen Grafik-Elementen 
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/ж 
cc У5.с +L 

1n У5.о -1¢32 

s 

/* 

AA Gdlzy's VSprite Demo 

к/ 

#include <intuition/intuitionbase.h> 
#include <graphics/collide.h> 
#include <ехес/%урев.һ> 

#include <exec/memory.h> 

#include <funetions.h> 

#include <graphics/gels.h> 

#include ”GElTool.h” 

#define VS 20 


SHORT 141-0,142-0; 
WORD vX[VS}={ 
5,-5,5,-5,4,-4,4,-4,2,-3,3,-3,2,-2,2,-2,1,-1,1,-1 


la 
WORD vYLVSJ={ 
1,1,1,1,2,2,2,2,3,3,3,3,4,4,4,4,5,5,5,5 


}; 

WORD *Ball,BallDat[]s[ 
0х1800,0х2000,0х1000,0х6000,0х8С00,0хЕ200,0х8000, 
0хҒЕ00,0х0200,0хҒЕ00,0х7000,0х7000,0х3800,0х3800 

Із 

WORD Со1[5](3]=[ 


OxAAA, 0x888,0x555, 0xA00,0x800,0x500, 


200,40,250,150,0,1,CLOSEWINDOWI MOUSEBUTTONS, 
WINDOWCLOSEI RMBTRAPI ACTIVATE, NULL, NULL, 
DName , NULL, NULL, 0, 0,0, 0, (BENCHSCREEN 

Із 


struct IntuitionBase *IntuitionBase; 
struct GfxBase жоғхВаве; 
struct Window Sein? 

struct RastPort #RP; 

struct ViewPort жүр; 

struct VSprite *ISpLVS]; 
struct GelsInfo *GelsInfo; 

үл 

\\ Funktionen 

WA 


VOID BorCon(vsp,witch) 
struct VSprite *vsp; 
SHORT witch; 


SHORT id=vsp->VUserExt; 


vX[id]*=-1; 


vY[id]*=-1; 
] 
VOID MarCon(vspi,vsp2) 
struct VSprite *vsp1,*vsp2; 
{ ` 
Idlevspl-» VUserExt; 


if(((witch&LEFTHIT)==LEFTHIT)I | ( (v1teh&RIOHTHIT)--RIOHTHIT)) 


if(((witch&TOPHIT)==TOPHIT)I | ((witch&BOTTOMHIT) ==BOTTOMHIT) ) 


0хҒ00,0х800,0х800, 
0x0A0, 0x080, 0x050 
І; 


OxAA0,0x880,0x550, 


TEXT DName[]e" — Gólzy's VSprite-Demo"; 


struct NewWindow nwins[ 


Id2=vsp2->VUserExt; 


VOID CloseW() 


Fortsetzung auf Seite 146 


»Graphic Elements« - Teil 2: BObs 


Blitters Objekte 


Trotz ihrer Vorzüge gegenüber den Hard- 
ware-Sprites lassen unsere VSprites noch 
einige Wünsche offen. Die Blitter-Objekte 
werden den Wünschen des verwöhnten 
Programmierers auf jeden Fall gerecht. 


Von Arno Gölzer 


ie Verwandtschaft der 
VSprites mit den Hard- 
ware-Sprites läßt sich 
nicht leugnen. Die »Blitter-Ob- 
jects«, kurz BObs genannt, sind 
dagegen völlig andere Grafik- 
Elemente. Ihr Name verrät es: 
nicht der Copper, sondern sein 
Kollege, der Blitter, ist Ursprung 
ihres Wesens. Die BObs wer- 
den aber, ebenso wie die VSpri- 
tes, nicht rein hardwaremäßig, 
sondern mittels ausgeklügelter 
System-Software generiert. 
Die Arbeit des Blitter konzen- 
triert sich auf das Kopieren der 
BOb-Grafik in die Zeichenflä- 
che sowie das Retten und 
Rückkopieren des alten Inhalts 
der Zeichenfläche. BObs dür- 
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fen, solange damit die Anzahl 
der Bitebenen (Planes) des 
Ziel-RastPorts nicht überschrit- 
ten wird, aus bis zu fünf Planes 
bestehen. Anzahl und die Regi- 
sternummern der Farben sind 
von der Anzahl der BOb-Planes 
und deren Plazierung in den 
Ziel-Planes abhängig. 

Die Breite der BObs ist, an- 
ders als die der Sprites, nicht 
auf 16 Pixel beschränkt. Die 
maximale Breite sind 64 Words, 
was 16 x 64=1024 Pixel (Blitter- 
Limit) entspricht. Die maximale 
Höhe beträgt ebenfalls 1024 Pi- 
xel. Die einzelnen Punkte eines 
Sprites haben, unabhängig von 
der. Auflösung des aktuellen 
Displays, immer die Größe ei- 
nes Bildschirmpixels im LoRes- 
Modus. Die Bildpunkte einer 
BOb-Grafik entsprechen dage- 


gen in ihrer Größe dem Pixelfor- 
mat des Displays, in das sie 
kopiert wird. BObs sind also 
sehr flexibel und gut für die 
Spieleprogrammierung geeig- 
net. Doch diese Flexibilität hat 
auch ihren Preis - der Aufwand 
für die Initialisierung der not- 
wendigen Strukturen ist hoch. 
Neben der »GelsInfo«- und der 
»VSprite«-Struktur, muß noch 
eine spezielle BOb-Struktur mit 
Werten versorgt werden. 


Blitter macht’s 
möglich 


Glücklicherweise nimmt uns 
das Headerfile »GELTool.h« (Li- 
sting 3 des ersten Teils) ein gro- 
Bes Stück der anfallenden Ar- 
beit ab. Zunáchst aber - als 
Grundlage - die Besprechung 
der Strukturen und deren Be- 
sonderheiten in bezug auf 
BObs. Mit der »GelsInfo«-Struk- 
tur, de eine Kette von Grafik- 
Elementen verwaltet, haben wir 
uns bereits im Teil 1 des »Gra- 
phic Elements«-Artikels einge- 
hend befaßt, so daß wir hier auf 


eine ausgedehnte Bespre- 
chung verzichten können. 

Allein zur Vereinbarung der 
ersten Komponente - Sie erin- 
nern sich an das Byte »spr- 
Rsrvd« - ist noch ein Wort zu sa- 
gen. Diese Variable gibt an, 
welche Hardware-Sprites für 
den Einsatz der VSprites abge- 
zweigt werden sollen. Besteht 
Ihre »GEL«-Kette nur aus BObs, 
können Sie »sprRsrvd« auf 0 
setzen. 

Die Vereinbarung der Struk- 
tur übernimmt, wie auch bei 
den VSprites, die »GELTool.h«- 
Funktion: 


Struet GelsInfo xGI; 


GI-GetGelsInfo(R,s,1,t, 
r,b); 


Als Gegenstück dazu gibt 
»FreeGelsinfo(Gelsinfo)« den 
für die Struktur notwendigen 
Speicher wieder frei. 

Weit interessanter als die 
»Gelsinfo«-Struktur wird für uns 
jetzt die VSprite-Struktur. Tat- 
sáchlich - wir müssen uns auch 
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struct VSprite 


| 


struct VSprite XNextVSprite; /% nächstes GEL іп der Kette %/ 
struct VSprite *PrevVSprite; /* letztes GEL-Kettenglied */ 
struct VSprite *DrawPath; /* Zeichen-Reihenfolge der GELs %/ 
struct VSprite *ClearPath; /* Reihenfolge - Lóschen und 
Restaurieren */ 
WORD OldY, 014Х; /* Position des geretteten 
Zeichenflächen-Rechtecks */ 
WORD Flags; /* GEL-Flags - unterscheide: User- und Systemflags */ 
WORD Y, X; /* die Position der linken oberen Ecke des GELs */ 
WORD Height; /* die Höhe des GEL in Pixel */ 
WORD Width; /* die GEL-Breite in WORDs (16 Bit) */ 
WORD Depth; /* Anzahl der GEL-Planes (max. 5 - 
bei VSprites immer 2) */ 
/* mit HitMask zusammen zur 
Kollisionserkennung nötig X/ 
/* Kollisionserkennung - Bit 0 gesetzt: 
Border-Kollision %/ 
WORD *ImageData;/* die im Chip-Memory gelagerten GEL-Bilddaten */ 
WORD *BorderLine; /* ODER-Verknüpfung aller GEL-Zeilen */ 
WORD *CollMask;/X ODER-Verknüpfung aller GEL-Planes (Schatten) %/ 


WORD MeMask; 


WORD HitMask; 


WORD *SprColors; 
struct BOb *VSBOb; 


/* das Farb-Array für VSprites %/ 


/* die BOb-Struktur beschreibt das Blitter- 


Objekt X/ 


BYTE PlanePick; 


BYTE PlaneOnOff; 


/* in welche Plane(s) soll der BOb kopiert 
werden? */ 
/* in welche Planes gehórt der » »Bild- 


Schatten<<? #/ 


VUserStuff VUserExt; 


Ji 


/* Variable für den eigenen Gebrauch #/ 


Listing 1. Auch BObs werden unter anderem über die 


VSprite-Struktur verwaltet 


bei der Programmierung von 
BObs mit ihr bescháftigen. Li- 
Sting 1 zeigt sie noch einmal, 
mit einer Kurzbeschreibung al- 
ler Variablen. Einige davon ha- 
ben wir ja bereits nàher be- 
leuchtet. 

Die ersten beiden Adressen 
verweisen auf das náchste bzw. 
vorhergehende . Glied‘ der 
»GEL«-Kette. »DrawPath« ent- 
hält die Reihenfolge, in der die 
Objekte auf den Bildschirm ge- 
zeichnet werden. »ClearPath« 
beschreibt, in welcher Folge 
der Blitter die überschriebenen 
Bereiche der Zeichenfläche re- 
staurieren muß. Der Blitter ko- 
piert vor der Darstellung eines 
»SAVEBACK«-BObs (siehe 
auch unter Flags) den recht- 
eckigen Bereich der Zeichen- 
fläche, der mit der BOb-Grafik 
überschrieben wird, in einen 
Puffer. Nach dem Bewegen 
oder Löschen des BObs gibt 
der Blitter den Inhalt des Puf- 
fers zurück. Die beiden »Word«- 
Variablen »OldX« und »OldY« 
enthalten die Position der lin- 
ken oberen Ecke des Zielbe- 
reichs. 

Einige der in »graphics/gels. 
h« definierten VSprite-Flags ha- 
ben wir schon kennengelernt. 
Hier eine Liste, die auch die 
BOb-Flags berücksichtigt: 

VSPRITE: stellt die VSprite- 
Struktur auf die Arbeit mit 
VSprites ein 

SAVEBACK: der für die Dar- 
stellung eines BObs nótige 
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struct BOb 


{ 
WORD Flags; 


WORD *SaveBuffer; 


Know-How 


handelt sich dabei nicht um 
den »Depth«-Wert, sondern um 
die Summe Depth+Anzahl der 
Planes, die mit dem Bild-Schat- 
ten überschrieben werden (sie- 
he unter »PlanePick«/»Plane- 
OnOff«). Das System fordert 
den notwendigen Speicher 
nicht an, sondern der Program- 
mierer muß - solange er nicht 
über »GELToolh« verfügt - 
selbst für einen entsprechend 
groBen Puffer sorgen. 

OVERLAY: die gelóschten 
(nicht gesetzten) Punkte der 
BOb-Grafik erscheinen nach 
dem Setzen des »OVERLAY«- 
Flags durchsichtig. Unser Bei- 
spielprogramm (Listing 3). ver- 
deutlicht den »OVERLAY«-Mo- 
dus. Nur wáhrend dem Festhal- 
ten der linken Maustaste be- 
wegt sich der BOb mit gesetz- 
tem »OVERLAY«-Bit. 

GELGONE: wird vom System 
gesetzt, wenn sich ein »GEl«, 
gleichgültig, ob VSprite oder 
BOb, außerhalb des mittels der 
»Gelsinfo«-Strukur beschriebe- 
nen Rechtecks befindet. 

Die folgenden Elemente kón- 
nen wie unter VSprites be- 


/* die BOb-Flags - unterscheide: User- und 
Systemflags */ 
/* der Puffer für den überschriebenen 


Zeichenbereich */ 
WORD *ImageShadow; /* der Bild-Schatten (ODER-Verknüpfung 
der Planes) */ 
struct BOb *Before; /* wird vor dem hier beschriebenen BOb 
gezeichnet */ 
struct BOb *After; /* wird nach dem hier beschriebenen BOb 
gezeichnet */ 
struct VSprite *BObVSprite; /* die VSprite-Struktur (Listing 1)*/ 
struct AnimComp *BObComp; /* die Adresse einer AnimComp- 


Struktur */ 


struct DBufPacket *DBuffer; /* Buffer fiir Double-Buffering- 


Betrieb */ 


BUserStuff BUserExt; /* Variable fiir den eigenen Gebrauch */ 


Із 


Listing 2. Für ein BOb ist die Vereinbarung der 
BOb-Struktur nötig 


Speicherbereich wird an die 
Adresse »SaveBuffer« der BOb- 
Struktur gerettet. Nach der Dar- 
stellung wird die Zeichenfläche 
restauriert. Ist »SAVEBACK« 
nicht gesetzt, zeichnet der BOb 
bei der Bewegung wie ein Pin- 
sel in den »RastPort«. 

Der SaveBuffer muß groß ge- 
nug sein, um alle überschriebe- 
nen Planes wiederherstellen zu 
können. Die Speichergröße er- 
rechnet sich aus: 


16xWidthxHeight«P 


Der Faktor 16 rechnet den 
»Word-Width«-Wert in Pixel um. 
Das »P« steht für die Anzahl der 
überschriebenen Planen. Es 


schrieben gehandhabt werden. 
Die Image-Daten liegen auch 
hier in einem Array »planewei- 
se« hintereinander, nur dürfen 
wir bis zu fünf Planes verwen- 
den. 

Jede BOb-Plane muß be- 
Schrieben werden. Die Bitkom- 
bination an Stellen von überein- 
anderliegenden Planes ergibt 
das Register, aus der die Farbe 
stammt, mit der diese Stelle ge- 
fárbt wurde (siehe Blitter-Arti- 
kel, Seite 72, Bild 1). 

Bei »BorderLine« und »Coll- 
Mask« ist zu beachten, daß 
BObs auch mehrere Words 
breit sein dürfen. Reservieren 
Sie ausreichend Speicher. 


»BorderLine« beinhaltet - 
nach dem Aufruf der »Init- 
Masks()«-Funktion - das Ergeb- 
nis der ODER-Verknüpfung al- 
ler »GEL«-Zeilen. Der erforderli- 
che Speicher errechnet sich 
daher aus 16 x Width. »Coll- 
Mask« muB das Ergebnis der 
ODER-Verknüpfung (Bild-Schat- 


BObs in 
allen Farben 


ten) aller» GEL«-Planes aufneh- 
men kónnen. Der Speicherbe- 
darfist daher der gleiche wie für 
eine Plane: 

16 x Width x Height. 

Die Adresse »SprColors« ist 
nur bei der Verwendung der 
VSprites von Interesse. BObs 
kommen ohne Farbpalette aus, 
da sich ihre Farbe aus Anzahl 
und Belegung der BOb-Bit- 
Planes ergibt. 

Der Pointer »VSBOb« ver- 
weist auf die BOb-Struktur, die 
das Blitter-Objekt näher be- 
schreibt. Bevor wir diese Struk- 
tur unter die Lupe nehmen, wol- 
len wir noch die Funktion der 
restlichen VSprite-Strukturva- 
riablen besprechen. 

Die beiden folgenden Werte 
sind für die Farbgebung des 
BObs von größter Bedeutung. 
Das Byte »PlanePick« teilt dem 
System mit, welche RastPort- 
Planes mit den BOb-Planes 
überschrieben werden sollen. 
Möchten Sie z.B. in einem Dis- 
play mit fünf Planes die erste 
und die vierte RastPort-Plane 
mit den beiden Planes (Depth= 
2) eines BObs überschreiben, 
so erhält PlanePick den Wert 
»0001001 = 9: 


Plane: 54321 
PPiek: 0.10 01 


»PlaneOnOff« gibt an, in wel- 
che der restlichen Planes, im 
Beispiel die Planes 2, 3 und 5, 
der Bildschatten (ODER-Ver- 
knüpfung aller Planes) kopiert 
werden soll (siehe auch unter 
»lmageShadows). 

Nach der Belegung der 
VSprite-Struktur errechnen Sie 
mit dem Aufruf der Funktion 
»InitMasks(VSprite)« die Werte 
für »BorderLine« und »Coll- 
Mask«. Bevor wir das Blitter- 
Objekt auf dem Bildschirm ver- 
wenden können, müssen wir es 
noch etwas näher beschreiben. 
Dies erfolgt über die BOb- 
Struktur (Listing 2). Die Adresse 
dieser Struktur tragen wir unter 
»VSBOb« іп der VSprite-Struk- 
tur ein. 

Als erste Variable begegnen 
wir einem Word zur Aufnahme 
der speziellen BOb-Flags. Wir 
unterscheiden sieben Flags: 
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BObISCOMP: das BOb ge- 
hört zu einer Animationskom- 
ponente. Die Adresse »BOb- 
Comp« der BOb-Struktur zeigt 
auf die entsprechende Anim- 
Comp-Struktur (siehe dort). 

BOBSAWAY: ist dieses Flag 
gesetzt, wird das BOb beim 
nächsten »DrawGList()«-Aufruf 
gelöscht. Das in »graphics/gels. 
h« definierte Makro »RemBOb 
(&BOb)« macht von dieser Mög- 
lichkeit Gebrauch. Möchten Sie 
ein BOb sofort löschen, rufen 
Sie die Funktion »RemIBOb(& 
BOb,&RP8VP)« auf. Beide Funk- 
tionen erwarten als Parameter 
die Adresse der BOb-Struktur. 
»RemiBOb()« benötigt zusätz- 
lich noch die Adressen der zu- 
ständigen.Strukturen »RastPort« 
und »ViewPort«. Beachten Sie 
bitte, daß im »Double Buffering«- 
Modus das BOb erst nach dem 
zweiten Aufruf der »DrawGList 
( )«-Funktion (für die zweite Bit- 
Map) gelöscht wird. 

BObNIX: wird vom System 
nach der Beendigung der 
»DrawGList()«-Funktion ge- 
setzt, wenn das BOb vollstän- 
dig gelöscht wurde (wichtig im 
Double-Buffering-Modus) 

BDRAWN: wird vom System 
gesetzt, nachdem das Blitter- 
Objekt gezeichnet wurde 

BWAITING: wird vom Sy- 
stem gesetzt, wenn noch Grafik- 
Elemente einer »GEL«-Kette vor 
dem mit dieser Struktur be- 
schriebenen BOb zu zeichnen 
sind. 

SAVEBOb: siehe VSprite- 
Flag »SAVEBACK« 

SAVEPRESERVE: wird im 
Double-Buffering-Modus vom 
System benutzt. 

Es folgt die Adresse des Sa- 
veBuffers. Weiter oben, bei der 
Besprechung des »SAVEBACK«- 
Flags, haben wir bereits vom 
»SaveBuffer« gehört. Hier legt 
das System den Bereich der 
Zeichenfläche ab, der vom BOb 
überschrieben wird. So kann 
die Fläche nach dem Löschen 
des BObs wiederhergestellt 
werden. 

»Image-Shadow« und »Coll- 
Mask« der VSprite-Struktur ver- 
weisen beide auf die gleiche 
Adresse: den Bild-Schatten 
(ODER-Verknüpfung aller Pla- 
nes) des BOb-Images. Dieser 
Bildschatten wird in die mittels 
»PlaneOnOff« bestimmten Pla- 
nes kopiert. Auf diese Weise 
wird die Farbe der einzelnen 
BOb-Pixel festgelegt, sofern 
man weniger BOb-Planes als 
RastPort-Planes definiert hat. 

Die Adressen »Before« und 
»After« zeigen auf die BOb- 
Strukturen, die der Blitter vor, 
beziehungsweise nach dem 
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gerade beschriebenen BOb 
zeichnen soll. »BObVSprite« 
zeigt auf die VSprite-Struktur, 
deren Adresse »/SBOb« auf die 
eigene BOb-Struktur verweist. 
So sind beide Strukturen mit- 
einander verkettet. 

Der folgende Pointer zeigt 
auf eine »AnimComp«-Struktur. 
Blitter-Objekte können nicht 
nur auf dem Bildschirm ver- 
schoben, sondern auch in der 
Art eines Daumenkinos ani- 
miert werden. 

Ein solcher »Film«, beste- 
hend aus mehreren einzelnen 
Bildern, nennt man eine Anima- 
tions-Komponente. Mehrere 
solcher Elemente lassen sich - 
mittels der »AnimOb«-Struktur - 
zu einem Animations-Objekt 
zusammenfassen. 

Ein fahrendes Auto mit sich 
drehenden Rádern, einer flat- 
ternden Fahne und dem grin- 
senden Fahrer kónnte z.B. als 
Animations-Objekt definiert sein. 


Silicon Motion 


Ráder, Fahne, Fahrer und Auto 
wären in diesem Fall eigenstän- 
dig animierte Grafik-Elemente: 
Animations-Komponenten. 

Das ganze Objekt kann, wah- 
rend die »Komponenten-Filme« 
laufen, kontinuierlich verscho- 
ben und beschleunigt oder ver- 
zógert werden. Jedoch ist der 
dafür notwendige Aufwand ent- 
sprechend hoch und eine ge- 
naue Beschreibung würde den 
Rahmen dieses Artikels spren- 
gen. 

Es geht weiter mit der Adres- 
se »DBuffer« der BOb-Struktur. 
Sie zeigt im »Double Buffering«- 
Modus auf eine »DBufPacket«- 
Struktur, ansonsten tragen Sie 
hier 0 ein. Beachten Sie bitte, 
daß ein Wert ungleich 0 den 
Double-Buffering-Modus akti- 
viert. In diesem Modus arbeitet 
man mit zwei BitMaps, zwi- 
schen welchen ständig umge- 
schaltet werden. Diese Technik, 
man verwendet sie bei beson- 
ders großen BObs, ist im Bei- 
trag zu »Double Buffering« in 
diesem Sonderheft auf Seite 
68 ausführlich beschrieben. 
Nebenbei: Manchmal ist es gar 
nicht notwendig, auf diese kom- 
plizierte Technik zurückzugrei- 
fen: ein synchronisierendes 
»WaitTOF(« vor der BOb- 
Bewegung reicht oft schon aus. 

Das System braucht im »Dou- 
ble Buffering«-Modus für die 
zweite BitMap einen weiteren 
»SaveBuffer«. Diesen Spei- 
cherbereich, er hat die gleiche 
Größe wie der weiter oben be- 
schriebene »SaveBuffer«, müs- 
sen Sie wieder selbst reservie- 


ren. Die Adresse des Speicher- 
bereichs erwartet das System 
in der Komponente »BufBuffer« 
der »DBufPacket«-Struktur: 


DBufPacket- > BufBuffer- 
Adresse; 


Die anderen Werte dieser 
Struktur, wie etwa die x/y-Posi- 
tion des wiederherzustellenden 
Display-Bereichs, sind nur für 
das System wichtig. 

Die letzte BOb-Strukturvaria- 
ble, »BUserExt«, ist vom Typ 
»BUserStuff« Das in »gra- 
phics/gels.h« definierte Symbol 
kann wie »VUserStuff« zum Ein- 
binden eigener Variablen in die 
Struktur eingesetzt werden. 
Nach der Initialisierung aller 
Strukturen fügt die Funktion 
»AddBOb(&BOb,&Rp)« das 
neue Grafikelement (BOb) in 
die »GEL«Liste des »Rast- 
Ports« (RP) ein. 

Sie sehen, der Initialisierungs- 
aufwand beim Arbeiten mit 
BObs ist tatsáchlich beachtlich. 
Drei große Strukturen verlan- 
gen die Versorgung ihrer Kom- 
ponenten mit passenden Wer- 
ten. Dabei müssen viele Spei- 
cherbereiche unterschiedlicher 
GróBe allokiert werden. Die 
SpeichergróBe ist von anderen 
Strukturvariablen abhängig 
und zu berechnen etc. 

Aber kein Grund zur Resi- 
опайоп! Die Vorzüge der 
Blitter-Objekte sind zu ver- 
lockend - und nicht zuletzt: Wir 
verfügen über ein Werkzeug, 
mit. deren Hilfe die Program- 
mierung der Amiga-Grafikobjek- 
te zum Kinderspiel wird: »GEL- 
Tool.h« (Listing 3 von Teil 1). 

Die Funktionen (bzw. Ma- 
kros) »GetVSprite()«, »Free- 
VSprite()« und »MoveVSprite()« 
haben wir schon im ersten Teil 
dieses Artikels getestet. Die 
gleichen Funktionen (Makros) 
existieren auch für BObs. Nach 
dem Aufruf der »GetGels()«- 
Funktion richtet die Funktion 
»GetBOb()« die Strukturen 
VSprite und BOb vollständig 
ein. Dabei wird der notwendige 
Speicher automatisch errech- 
net und allokiert, sowie das 
BOb in die »GEL«-Liste einge- 
fügt: 


struct BOb xb; 
b=GetBOb(rp,f,bf,x,y,W, 
h,d,me,hi,da,pp,po,dbuf, 


vu,bu); 


Wie unschwer zu erkennen 
ist, liefert »GetBOb()« die Adres- 


se einer BOb-Struktur. Die Pa- - 


rameter bedeuten, von links 
nach rechts: 


rp: die Adresse des Rast- 
Ports, in dem der BOb einge- 
setzt werden soll 

f: die Flags der VSprite- 
Struktur 

bf: die Flags der BOb-Struk- 
tur 

x,y: die Position der linken 
oberen Ecke des BObs, in be- 
zug auf die linke obere Display- 
Ecke 

w: die Breite in Words 

h: die Höhe in Pixel 

d: die Anzahl der BOb- 
Planes (Depth) 

me: das »MeMask«-Byte der 
VSprite-Struktur für die Kolli- 
sionsabfrage 

hi: das »HitMask«-Byte der 
gleichen Struktur 

da: die Adresse des Image- 
Daten-Arrays 

pp: der »PlanePick«-Wert 

po: der »PlaneOnOff«-Wert 

dbuf: eine Boolesche Varia- 
ble; ist sie gleich »TRUE«, rich- 
tet die Funktion den für den 
Double-Buffering-Modus not- 
wendigen Speicher ein 

vu: »VUserStuff« 

bu: »BUserStuff« 

Alle weiteren Werte errech- 
net »GetBOb()« selbst. 

Das Gegenstück hierzu - 
FreeBOb(bob,rpvp,kill) - gibt 
den fiir die BOb-Struktur und 
deren Buffer reservierten Spei- 
cher an das System zuriick. Der 
erste Parameter zeigt auf die 
betreffende BOb-Struktur. Die 
Bedeutung der anderen Para- 
meter ist mit jenen der »FreeV- 
Sprite()«-Funktion identisch. 

Das Synonym für »MoveV- 
Sprite()« heißt erwartungsge- 
тав »MoveBOb(&BOb,&RP.&VP, 
Xy)«. Die Funktion bewegt ei- 
nen einzelnen BOb um x Pixel 
in der Horizontalen und um y Pi- 
xel in der Vertikalen. Die beiden 
anderen Parameter sind die 
Adressen der Strukturen »Rast- 
Port« und »ViewPort«. 

Unser Beispiel (Listing 3) de- 
monstriert die genannten »GEL- 
Tol.h«-Funktionen. Ein 192 x 40 
Pixel groBes BOb mit zwei Pla- 
nen bewegt sich über den 
Workbench-Screen und reflek- 
tiert an dessen Grenzen. 

Da wir Ihnen nicht zumuten 
wollen, die Riesenmenge an 
Image-Daten abtippen zu müs- 
sen, haben wir auf bereits be- 
stehende Daten zurückgegrif- 
fen und so einen recht interes- 
santes BOb geschaffen. Las- 
sen Sie uns einen Blick in den 
Quellcode des, dank »GEL- 
Tool.h« recht kurzen, Demos 
werfen. * 

Alle Vorarbeiten, wie das Off- 
nen von Libraries und Win- 
dows, übernimmt »OpenW()«. 
»InitBitMap()« initialisiert darin 
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eine Dummy-BitMap, die als 
Plane-Pointer zwei Zeiger aufje 
eine Hälfte des für das Image 
reservierten Speicherbereichs 
erhält. 

Mittels »BItBitMap()« kopie- 
ren wir die linke obere Screen- 
Ecke in diesen Bereich, denn 
dort befindet sich unser Win- 
dow. So haben wir schnell die 
Daten für das BOb-Image be- 
sorgt: ein BOb mit dem Ausse- 
hen eines Windows. Den Aufruf 
der »GetGelsinfo()«-Funktion 
richtet die »GelsInfo«-Struktur 
ein. Vor der Festlegung der bei- 
den anderen Strukturen, legen 
wir die Kollisionsroutine für den 


»GEL«-Rand fest: »BorCon()« 
negiert den Geschwindigkeits- 
vektor, der für die Kollision ver- 
antwortlich war (siehe Teil 1: 
Kollision zwischen Graphic-Ele- 
ments und Border). 

Die Funktion »GetBOb()« 
macht ihrem Namen alle Ehre 
und beschafft uns ein »SAVE- 


BACK«-BOb mit den ge- 
wünschten Spezifikationen. 
»DrawGels()« zeichnet die 


»GEL«-Kette in den RastPort. 
In der Hauptfunktion »main()« 
bewegt »MoveBOb(« unser 
neu erschaffenes Blitter-Objekt 
über den Bildschirm. Stellt »Get- 
Message()« dabei die Betáti- 


. KnowHow 


gung der linken Maustaste fest, 
so setzen wir in der VSprite- 
Struktur das »OVERLAY«-Flag. 
Das BOb wird dann augenblick- 
lich an allen Stellen, an denen 
die Hintergrundfarbe sichtbar 
ist - verblüffend aber wahr - 
durchsichtig. 

Nach der Anwahl des Close- 
Gadgets gibt »CloseW()« den 
reservierten Speicher wieder 
ап ‘das System zurück und 
beendet das Programm. Viel- 
leicht ersetzen Sie einmal - nur 
um zu sehen, was passiert - die 
beiden Zeilen im »else«-Zweig 
der »main()«-Funktion durch die 
folgenden Zeilen: 


if(code--SELECTDOWN) 
BOb- > BObVSprite- 

> Flags&- SAVEBACK; 
else BOb->BObVSprite- 
> Flags | SAVEBACK; 


Erstaunt? In dieser Art finden 
Sie sicher noch eine Menge an- 
derer Móglichkeiten zur Mani- 
pulation ~ viel Spaß dabei! 

Martin Jobst/so 


Arno Gölzer ist ein Mann der ersten Stunde. 
Er schreibt seit über zwei Jahren für das AMI- 
GA-Magazin und die AMIGA-Sonderhefte. Sie 
kónnen ihn erreichen über unsere Verlagsan- 
schrift (Markt & Technik Verlag AG, Redaktion 
Sonderhefte, z. Hd. Arno Gölzer, Hans-Pinsel- 
Straße 2, 8013 Haar bei München). 


/* 


се BOb.c +L 
1n BOb.o -1032 


WA 
/* 


\\ Gélzy's BOb Demo 


WA 


#include <intuition/intuitionbase.h> 


# include 
# include 


<graphics/collide.h > 
<ехес/%урев.һ> 


#include <exec/memory.h> 
#include <functions.h> 


# include 


<graphics/gels.h> 


#include "GElTool.h" 


#define HEIGHT 40 
#define WIDTH 192 


WORD vX=4,vY=2; 
PLANEPTR Image; 
TEXT DName[]=” Gölzy's BOb-Demo"; 


struct 


NewWindow nwin={ 


0,0, WIDTH, HEIGHT, 0,1,CLOSEWINDOWI MOUSEBUTTONS , WINDOWCLOSEI ACTIVATE, 


Із 

struct 
struct 
struct 
struct 
struct 
struct 
struct 
struct 
struct 


E) 


NULL, NULL, DName , NULL, NULL, 0,0, 0, 0, NBENCHSCREEN 


IntuitionBase 
GfxBase 
Window 

Screen 
RastPort 
BitMap 
ViewPort 
GelsInfo 

BOb 


*IntuitionBase; 
` XGfxBase; 

*win; 

*Screen; 

“RP; 

*BM, DBM; 

жүр; 

*GelsInfo; 

*BOb; 


\\ Funktionen 


M. 


VOID BorCon(vsp,witch) 


} 


struct VSprite *vsp; 
SHORT witch; 


if (((witch&LEFTHIT) ==ЕРТНІТ) | ((witch&RIGHTHIT) ==RIGHTHIT) ) 
vX*z-1; 

if(((witch&TOPHIT)==TOPHIT)I | ((witch&BOTTOMHIT) ==BOTTOMHIT) ) 
vY*=-1; 


VOID CloseW() 


£ 


} 


1f(BOb) 

if(Image) 
1f(GelsInfo) 
if(win) 
if(GfxBase) 
if(IntuitionBase) 
exit(0); 


FreeBOb(BOb, RP, VP, 1) ; 
FreeRaster(Image,WIDTH, 2*HEIGHT) ; 
FreeGelsInfo(GelsInfo) ; 
CloseWindow(win) ; 
CloseLibrary(GfxBase) ; 
CloseLibrary(IntuitionBase); 


VOID Орепм() 


| 
| 


if(!(IntuitionBase=(struet IntuitionBase X) 
OpenLibrary(^intuition.library",0))) CloseW(); 


| AMIGA-SONDERHEFT 7 


Sereen=IntuitionBase-> ActiveScreen; 
if(!(GfxBase=(struct GfxBase %) 
OpenLibrary("graphics.library",0))) CloseW(); 
if(!(win=OpenWindow(&nwin))) CloseW(); 
VPz&Screen- > ViewPort; 
RP=&Screen->RastPort; 
BM=RP- > BitMap; 
InitBitMap(&DBM,2, 192,20) ; 
if(!(Images(PLANEPTR)AllocRaster(WIDTH,2XHEIGHT))) CloseW(); 
DEN, Planes[0] -Image; 
DBM.Planes[1]-Image*RASSIZE(WIDTH,HEIGHT); 
B1tBitMap(BM,0, 0, &DBM, 0, 0, WIDTH, HEIGHT, OxCO, OxFF , NULL) ; 
Move(RP,8,26) ; , 
Text(RP,"Klick hier für OVERLAY”,22); 
if(!(GelsInfo-GetGelsInfo(RP,0,0,0,640,256))) CloseW(); 
SetCollision(0,BorCon,GelsInfo) ; 
if(! (BOb=GetBOb (RP, SAVEBACK,0,0,0,WIDTH/16,HEIGHT,2,0,1, 
Image,3,0,FALSE,0,0))) 
CloseW(); 
DrawGels(RP, VP); 


} 


ULONG GetMessage(code) 


( 


USHORT *code; 


struct IntuiMessage *msg; 
ULONG class=0; 


if(msg=(struct IntuiMessage *)GetMsg(win->UserPort))[ 
class=msg-> Class; 
*code=msg- > Code; 
ReplyMsg(msg) ; 

} 

return(class) ; 


) 


VOID main() 
( 
. USHORT code; 
ULONG class; 


Орепи(); 

while(1){ 
class=GetMessage(&code) ; 
if(elass==CLOSEWINDOW) break; 
else if(class==MOUSEBUTTONS) [ 
if(code--SELECTDOWN) BOb->BObVSprite->Flagsl = 
OVERLAY; 

else BOb->BObVSprite->Flags&= OVERLAY; 

} 


WaitTOF(); 
MoveBOb(BOb, RP, VP, vX, vY) ; 
DoCollision(RP); 

) 


CloseW(); 


Listing 3. Das BOb-Demoprogramm verwandelt ein 
Window in ein Blitter-Objekt 
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Von Arno Gölzer 


onglieren mit zwei Dis- 

plays ist für die meisten 

Spieleprogrammierer un- 
erläßlich, da nur so ohne gro- 
Ben Aufwand eine stehende 
Grafik in einer vorbeiziehenden 
Landschaft dargestellt werden 
kann. Um den Aufbau des Dual- 
Playfield-Modus leichter zu ver- 
stehen, sehen wir uns zunächst 


die BitMap-Struktur (Listing 1)- 


an. Sie enthält wichtige Infor- 
mationen über den Aufbau des 
Displays. So findet man darin 
auch die Adressen der einzel- 
nen Bitplanes. Das Array »Pla- 
nes[8]« bietet Platz für acht 
Adressen, die auf die Planes 
verweisen. Man nennt diese 
Adressen »Plane-Pointer«. Im 
Headerfile grafics/gfx.h ist so- 
gar ein Datentyp dafür definiert: 


typedef UBYTE xPLANEPTR; 


In der gegenwártigen Be- 
triebssystemversion kónnen je- 
doch nur sechs Planes zum 
Aufbau eines Displays genutzt 
werden. Dabei ist Plane 6 
Schon eine »Zusatzplane«, das 
nur bei den Spezial-ViewModi 
Verwendung findet. Einen die- 
ser Modi durchleuchten wir we- 
gen seiner Eignung zur Spiele- 
programmierung genauer: den 
DualPlayfield-Modus. 

Was verbirgt sich hinter die- 
sem Begriff? Wie bereits ein- 
gangs erwáhnt, setzt sich bei 
der Verwendung von DualPlay- 
field das Bild auf dem Monitor 
aus zwei übereinanderliegen- 
den Displays (Playfields) zu- 
sammen. Sie sind beide, ob- 


Zwei Bilder 
in einem 


wohl sie einem gemeinsamen 
ViewPort angehóren, voneinan- 
der völlig unabhängig. Jedes 
Playfield verfügt über eine eige- 
ne BitMap-Struktur mit bis zu 
drei Planes, über eine eigene 
RastPort-Struktur und schließ- 
lich noch über eine eigene 
Raslnfo-Struktur. Die erste Ras- 
Info-Struktur ist mit der zweiten 
über die Adresse »Next« verket- 
tet. Die ViewPort-Strukturkom- 
ponente »Raslnfo« verweist auf 
das erste Glied dieser Struktur- 
kette: 


ViewPort.RasInfo- 
RasInfo A; 
RasInfo A.Next = 
RasInfo B; 
RasInfo B.Next =NULL; 
In diesem Beispiel enthált die 
Struktur namens Rasinfo А 
die Informationen über Play- 
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Der DualPlayfield-Modus 


Der Amiga erlaubt 
die ^ gleichzeitige 
Darstellung von 
zwei übereinander- 
liegenden Displays. 
Diese auf den ersten 
Blick sinnlose Ein- 
richtung entpuppt 
sich als wahres Ju- 
wel in der Spiele- 
programmierung. 


field A, welches bildlich gespro- 
chen über Playfield B liegt und 
dieses teilweise verdeckt. Wie- 
so teilweise? Bei der Verwen- 
dung von drei Bitplanes pro 
Playfield stehen für jedes Play- 
field 23 = 8 Farben zur Verfü- 
gung. Die ViewPort-ColorMap 
ist aber für 16 Farben ausge- 
legt: 

ViewPort.ColorMap= 

GetColorMap(16); 


Die ersten acht Eintráge der 
ColorMap sind die Farben 0 bis 
7 des ersten Playfields, dage- 
gen entsprechen die zweiten 
acht Eintráge den Farben 0 bis 
7 des zweiten Playfields. Da 
man mit drei Planes nur acht 
Farben darstellen kann, werden 
die ersten acht Eintráge auf die 
folgenden acht kopiert. Somit 
ist die Farbe 0 gleich Farbe 8 
und 1 gleich 9 usw. Hier zwei 
Beispiele, die das gleiche be- 
wirken. 


SetAPen(&RP.B, 5); 
SetAPen(&RP. B, 13) ; 


Der erste Eintrag der Color- 
Map bestimmt wie gewohnt die 
Hintergrundfarbe. Wenn Sie 
nun in einem Playfield die Hin- 
tergrundfarbe (Eintrag O oder 8 
der ColorMap, je nach Play- 
field) setzen, zeichnen Sie nicht 
etwa in der erwarteten Farbe, 
sondern transparent! Das »dar- 


unterliegende« Playfield wird 
daher an diesen Stellen sicht- 
bar. Es stellt sich die Frage 
nach dem Sinn der zweiten 
transparenten »Farbe« (Eintrag 
Nummer 8 der ColorMap), da 
sich doch unter Playfield B 
nicht noch ein drittes Display 
befindet. Ganz einfach: Die An- 
ordnung der Displays kann 
durch das Setzen bzw. Löschen 
des Mode-Flags 


PFBA 


beliebig verändert werden. Ist 
PFBA gesetzt (Mode = DUAL- 
PF II PFBA), liegen die Play- 
fields gemäß den beiden letzten 
Buchstaben des Symbols, also 
B vor A. Lóscht man PFBA (Мо- 
de = DUALPF), so herrscht 
wieder, wie zu Beginn, die An- 
ordnung AB. Mit dieser Metho- 
de läßt sich übrigens sehr be- 


struct BitMap 
Í 
UWORD BytesPerRow; 
UWORD Rows; 
UBYTE Flags; 
UBYTE Depth; 
UWORD pad; 


kónnen auf Playfield A darge- 
stellt werden, wáhrend auf Play- 
field B das eigentliche Spiel zu 
sehen ist. Dabei müssen Sie zu 
keiner Zeit abfragen, ob bei- 
spielsweise ein Laserstrahl die 
Cockpit-Grafik Ihres UFOs zu 
überzeichnen droht, da beide 
Playfields völlig unabhängig 
voneinander sind. Die Displays 
können beliebig gegeneinan- 
der verschoben werden. Ein 
Playfield kann sogar nach allen 
Richtungen gescrollt werden, 
ohne daß dies einen Einfluß auf 
das andere hat. Die zuletzt ge- 
nannte Fáhigkeit haben wir uns 
in unserem Beispielprogramm 
zunutze gemacht, um den 
Speicher des Amiga einmal ge- 
nau unter die Lupe zu nehmen. 
In diesem Demo (Listing 2) sind 
zwei Playfields mit je drei Pla- 
nes definiert. Während die Gra- 
fik in Playfield A stándig sicht- 
bar ist, scrollt B, den Bewegun- 
gen des an Port Il angeschlos- 
senen Joysticks folgend, durch 
den Arbeitsspeicher Ihres Ami- 
gas! Ein Druck auf den Feuer- 
knopf beendet das Programm. 


Das Listing 
hilft 

Bevor Sie in dem Arbeits- 
speicher wühlen, noch ei- 
nen Blick ins Listing? Die Funk- 
tion OpenW() öffnet ein einfa- 
ches Grafik-Display im 
DUALPF-Modus. Die Struktu- 
ren RastPort, BitMap und Ras- 
Info sind in einem Array ange- 
legt, so daß die doppelte Initiali- 
sierung dieser Strukturen in ei- 
ner Schleife erfolgen kann. Der 
bedingte Ausdruck im Schlei- 
fenrumpf weist Raslnfo-[0]. Next 


/* Bytes pro BitMap-Zeile (Breite/8) */ 


/* Anzahl der Zeilen (Höhe) %/ 
/* ??? ungenutzt */ 


/* Anzahl der BitPlanen (BitEbenen) */ 
/* Platzhalter - PLANEPTR beginnen auf LONGWORD */ 


PLANEPTR Planes[8]; /* die Adressen der BitEbenen im Speicher */ 


s 
J; 


Listing 1. Die BitMap-Struktur verwaltet elementare Daten 


über das Grafikdisplay 


quem das sog. »Double-Buf- 
fering« realisieren. Mit dieser 
Technik befaßt sich jedoch ein 
anderer Artikel auf Seite 68 in 
diesem Heft. Uns interessiert 
was man denn mit dem Dual- 
Playfield-Modus in Spielen 
überhaupt anfangen kann. 
Nun, Elemente wie etwa das Ar- 
maturenbrett eines Autos, das 
Cockpit eines Raumfahrzeugs 
oder die Spielstandsanzeige 


die Adresse von Raslnfo[1] zu, 
während Raslnfo[1].Next den 
Wert Null erhált. Somit ist fest- 
gelegt: Raslnfo[0] gehört zu 
Playfield A und Raslnfo-[1] zu 
Playfield B. A liegt über B, da in 
ViewPort.Modes das Flag PFBA 
nicht gesetzt ist. Die Funktion 
CloseW() schließt alle Ressour- 
cen vor Programmende. Nach- 
dem InitStick() den Joystick an 
Port Il angemeldet hat, baut 
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E 

Aztec C 3.48 

cc DualPF.c +L 
1n DualPF.o -1c32 


Gölzy's DualPlayfield-Demo 


#include <exec/memory.h> 
#include <exec/types.h> 
#include <graphics/gfxbase.h> 

X include <graphics/view.h> 
#include <devices/inputevent.h> 
#include <devices/gameport.h> 
#include <functions.h> 


#define TMPDIM 200 
#define WIDTH 320 
#define HEIGHT 256 


WORD Buffer[10],ColTab[16]=[ 

0x888, 0x999 , OxAAA, OxBBB, OxCCC, OxDDD, OXEEE , OxFFF, 

0x000, OxFOO , OXOFO , OxOOF , OxFCO,0xOFF,0xC55,0x5F5 
); 
ULONG GPDev; 
struct GamePortTrigger GPTrigger-[ 

GPTF. UPKEYSI GPTF. DOWNKEYS,0,1, 1 

Із 
struct GfxBase *GfxBase; 
struct View *01dView,View; 
struct MsgPort *GPort; 
struct IOStdReq *GPRequest; 
struct InputEvent ReadStick; 
struct ViewPort VPort; 
struct RasInfo RasInfo[2]; 
struct BitMap ВМар(21; 
struct RastPort RP[2]; 
Struct TmpRas Raster; 
struct AreaInfo Alnfo; 
PLANEPTR Bitplane; 


VOID CloseW() 


[ 
REGISTER SHORT 1,); 


1f(01aView)[ 1 
LoadView(01dView) ; 
WaitTOF(); 


) 
FreeVPortCopLists(&VPort); 
FreeCprList(View.LOFCprList) ; 
if(VPort.ColorMap) FreeColorMap(VPort.ColorMap) ; 
for(1=0;1<2;1++) 
for(J20;) <3; J++) 
1f(BMap[1).Planes(J]) 
FreeRaster(BMap[1).Planes[]],WIDTH,HEIOHT); 
if(Bitplane) FreeRaster(Bitplane,TMPDIM, TMPDIM) ; 
if(GPDev) CloseDeyice(GPRequest) ; 
if (GPRequest) DeleteStdIO(GPRequest); 
if(GPort) DeletePort(GPort); 
if(GfxBase) CloseLibrary(GfxBase) ; 
exit(0); 


) 


VOID OpenW() 


[ 
REGISTER SHORT 1,); 


if(!(GfxBase-(struct GfxBase *) 

OpenLibrary("graphics.library",0)))  CloseW(); 
1f(1(GPort-CreatePort("GPort^,0))) CloseW(); 
1f(!(GPRequest-CreateStdIO(GPort))) CloseW(); 
if(GPDev=(ULONG) 

OpenDevice( "gameport.device",1,GPRequest,0)) CloseW(); 
if(!(Bitplane=AllocRaster(TMPDIM,TMPDIM))) —CloseW(); 
InitTmpRas(&Raster,Bitplane,RASSIZE(TMPDIM, TMPDIM)) ; 
InitArea(&AInfo,Buffer,2); 

O1dView=GfxBase->AotiVien; 
InitView(&View); 
View.ViewPort-&VPort; 
View.Modes ` -DUALPF; 
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] 


Know-How 


InitVPort(&VPort); 

VPort.DWidth =WIDTH; 

VPort.DHeight ^ =HEIGHT; 

VPort.RasInfo =&RasInfo[0]; 

VPort.ColorMap -бе%Со1огМар(16); 

VPort.Modes =DUALPF; 

for(1=0;1<2;i++){ 
InitRastPort(&RP[1]); 
InitBitMap(&BMap[i],3, WIDTH,HEIGHT); 
#ог(ј=0;)<3;]+)[ 

if(!(BMap[1].Planes[j]=(PLANEPTR) 
AllocRaster(WIDTH,HEIGHT))) CloseW(); 
BltClear(BMap[1].Planes[j],RASSIZE(WIDTH,HEIOHT) ,0) ; 

) 
RasInfo[i].BitMap  -&BMap[i]; 
RasInfo[i].RxOffset=0; 
RasInfo[i].RyOffset=0; 
RasInfo[1].Next z1?NULL:&RasInfo[1]; 
RP(1).BitMap -&BMap[1]; 
RP(1).TmpRas =&Raster; 
RP[i].Arealnfo s&AInfo; 

} 

LoadRGB4(&VPort,ColTab, 16) ; 

MakeVPort (&View, &VPort) ; 

MrgCop(&View) ; 


VOID SetGPRequest(doit,c,1,d) 


] 


BOOL doit; 
UWORD с; 
ULONG 1; 
APTR d; 


GPRequest->io_Command =c; 
GPRequest->io_Length =1; 
GPRequest->io_Data =d; 
if(doit) DoIO(GPRequest); 


VOID InitStick() 


| 


] 


UBYTE Data=GPCT_RELJOYSTICK; 
ULONG 1g=sizeof(struct GamePortTrigger), 
lissizeof(struct InputEvent); 


SetGPRequest(1,GPD_SETCTYPE, 1, &Data) ; 
SetGPRequest(1,GPD_SETTRIGGER, 1g, &GPTrigger); 
SetGPRequest(0,GPD_READEVENT, 11, &ReadStick) ; 


VOID DrawC(x,y,r) 


[ 


) 


SHORT x,y,r; 


AreaEllipse(&RP[0] x, y,r,r) ; 
AreaEnd(&RP(0]) ; 


VOID Print(RP,text,col,x,y) 


) 


struct RastPort XRP; 
STRPTR text; 
SHORT со1,х,у; 


SHORT i,lensstrlen(text); 


SetDrMd(RP,JAM1) ; 

for(1-1;1? -0;1--)[ 
SetAPen(RP, 1?2:001); 
Move(RP,x*i,y4i); 
Text(RP,text,len); 


VOID DrawvP() 


{ 


REGISTER SHORT 1,х,у; 


Ғог(1=1;1<9;1++)[ 


Listing 2. Das DualPlayfield-Demo gestattet einen 
ungetrübten Blick in den Arbeitsspeicher des Amiga 


SetAPen(&RP[O],i==820:1); 
DrawC( 90,128,95-5*1); while(1){ 
DrawC(229,128,95-5*1); SendIO(GPRequest) ; 
} WaitI0(GPRequest) ; 
Print(&RP[O], ”-*- Speicher-Brille -%-”,7,68,25); if(ReadStick.ie_Code==IECODE_LBUTTON) break; 
Print(&RP[0],"» »Joystick in Port II« < ",5,68,230); else{ 
Print(&RP[1], “Viel Spaß”,4,55,125); 1f(ReadStick.ie X) 
Print(&RP[1], "mit dem",4,60,140); RasInfo[1].RxOffset+=ReadStick.ie_X>028:-8; 
Print(&RP[1]," Dual ”,1,200,110); if(ReadStick.ie Y) 
Print(&RP[1], "Playfield”,6,193,130); RasInfo[1].RyOffset«-ReadStick.ie Ү>078:-8; 
Print(&RP[1], "View-Modus! ",6,185,150) ; ScrollVPort(&VPort); 


DrawVP(); 


LoadView(&View) 5 
) 


VOID main () 

( 
UBYTE Data=GPCT_NOCONTROLLER; 
Орепи(); 
InitStick(); 


DrawVP() die Grafik und den 
Text beider Playfields auf. Die 
Variable RP[O] steht für den 
RastPort des Playfields A und 
RP[1] für den von B. Der letzte 
Funktionsaufruf in DrawVP() 
öffnet das fertig erstellte Dis- 
play im DualPlayfield-Modus. In 
der Hauptschleife main() über- 
wachen wir in einer Endlos- 
schleife den GamePort. Je 
nach Richtung des Steuer- 
knüppels verschieben wir Play- 
field B unter A um 8 Pixel, was 


recht rasant ist. Dabei beachten 
wir die Grenzen des RastPorts 
B nicht. Somit wird, sobald wir 
ihn verlassen, der Inhalt des Ar- 
beitsspeichers sichtbar. Beson- 
ders interessant sieht der Spei- 
cher nach einem Grafikspiel 
aus! Registriert der GamePort 
den Feuerknopf, unterbrechen 
wir die Schleife, um mit Close- 
WO das Programm zu been- 
den. Es sollte noch erwähnt 
werden, daß der ganze »Zau- 
ber« durch die Betätigung der 


) 
} 


SetGPRequest(1,GPD. SETCTYPE, 1, &Data) ; 


CloseW(); 
) 


Listing 2. (Schluß) 


Tastenkombination «Linke Ami- 
ga n» unterbrochen wird. Der 
Workbenchscreen kommt nach 
vorne, kann aber, weil wir nicht 
mit einem Screen arbeiten, 
nicht mehr hinter unser Display 
geklappt werden. ' Abhilfe 
schafft z.B. ein Aufruf der Load- 
View()-Funktion, worauf wir 
aber in unserem Demo verzich- 
tet haben. Vielleicht konnten wir 
Sie mit diesem kurzen Artikel 
etwas neugierig machen, oder 
haben Sie sogar schon eine 


Idee, wo Sie den Modus einset- 
zen können? Wenn nicht, expe- 
rimentieren Sie doch einfach et- 
was mit dem Demo-Listing, um 
den DualPlayfield-Modus bes- 
ser kennenzulernen. pe 


Arno Gólzer ist ein Mann der ersten Stunde 
und schreibt schon einige Jahre für das AMI- 
GA-Magazin und die AMIGA-Sonderhefte. Sie 
kónnen ihn erreichen über unsere Verlagsan- 
schrift (Markt & Technik Verlag AG, Redaktion 
Sonderhefte, z. Hd. Herrn Gölzer, Hans-Pinsel- 
Straße 2, 8013 Haar bei München). 


FlieBende Bewegungen durch Double-Buffering 


Von Arno Gólzer 


chweißgenäßt, den Steu- 

erknüppel fest mit bei- 

den Hánden umschlun- 
gen, kámpft der Spieler in sei- 
ner Lieblingsflugsimulation ge- 
gen den Absturz - alles verge- 
bens! Macht nichts - fünf Se- 
kunden nach dem Crash, so- 
lange braucht er, um Chips und 
Cola nachzufüllen, wagt er ei- 
nen neuen Start. In atemberau- 
bender Geschwindigkeit fegt 
er mit seinem Flugzeug über 
die Startbahn. Die Landschaft 
fliegt nur so an ihm vorbei - die- 
mal klappt's bestimmt... 

Erst eine schnelle, sauber 
animierte Grafik läßt ein Spiel 
so realistisch erscheinen, daß 
eine derartige Begeisterung bei 
dem Spieler hervorgerufen 
wird. »Ruckelgrafiken« sind 
nicht gefragt - der Amiga kann 
es besser. Doch wie geht man 
als Programmierer vor? Zu- 
nächst können Sie festhalten: 
bei einer Animation muß, um 
die Illusion einer Bewegung zu 
erwecken, die Grafik ständig 
verändert werden. 
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Für weiche und fließende Bewegungen 

verwendet man eine besondere Technik: 

das Double-Buffering. Wir stellen Ihnen 
mehrere Methoden dazu vor. 


Zerlegen wir einen Bewe- 
gungsabschnitt, so ergeben 
sich die Schritte a) Grafik neu- 
berechnen und b) neue Grafik 
darstellen. Beide Schritte 
wechseln sich ständig ab. Da- 
bei ist es wichtig zu unterschei- 
den, ob vor der Darstellung die 
alte Grafik gelöscht werden 
muB oder diese mit dem neuen 
Bild überschrieben wird. Die 
Animationssysteme einiger Mal- 
programme arbeiten mit der zu- 
letzt genannten Methode. Geht 
es aber um Vektorgrafiken, wie 
bei unserem Beispiel »Flugsi- 
mulation«, muß das Zeichen- 


display vor jedem Animations- 
schritt gelóscht werden. Arbei- 
tet man mit einem Display, 
macht sich das Lóschen zwi- 
schen zwei Darstellungen als 
unangenehmes Flimmern be- 
merkbar. Darüber hinaus benó- 
tigen aufwendigere Grafiken re- 
lativ lange zum Aufbau, was 
Sich stórend bemerkbar macht. 

Die Lósung heiBt »Double- 
Buffering«. Bei dieser Technik 
wird, der Name läßt es vermu- 
ten, mit zwei hintereinanderlie- 
genden Zeichenpuffern oder 
mit zwei Displays gearbeitet. 
Wáhrend die Grafik auf dem 


vorderen Bildschirm zu sehen 
ist, wird der hintere gelóscht 
und nach einer Neuberech- 
nung die abgeánderte Grafik 
dargestellt. Dann vertauscht 
man die Bildschirme und das 
Spiel beginnt von neuem: hin- 
tere Grafik lóschen, Grafik ver- 
deckt zeichnen, Bildschirme 
vertauschen etc. Alle bislang 
stórende Effekte wie Lóschen 
oder Neuzeichnen des Bildes 
erfolgen versteckt im Hinter- 
grund. Beim Arbeiten mit Intui- 
tion können Windows und 
Screens als Zeichenfläche ge- 
nutzt werden: 


for(index-0,..;..;..)Í 
ZeichneGrafik(&Window 
[index]); 
WindowToFront (&Window 
[index]); 
index-index?0:1; 


) 
In diesem Listingausschnitt 
benutzen wir zwei gleich große 


Fenster, die sich an der glei- 
chen Screen-Position befinden. 
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Im Schleifenrumpf des Pro- 
grammfragments baut die 
Funktion »ZeichneGrafik()« auf 
dem im Hintergrund liegenden 
Window[0] eine Grafik auf. 
Dann klappt WindowToFront() 
das Fenster in den Vorder- 
grund. Der bedingte Ausdruck 
schaltet die Indexvariable wie 
ein FlipFlop je nach Ausgangs- 
wert auf 0 oder 1 um. Das be- 
deutet: Im náchsten Schleifen- 
durchlauf wird die Grafik in Win- 
dow[1] aufgebaut, das dann 
nach vorne gebracht wird. Bei- 
de Windows wechseln sich ab, 
bis das Schleifenkriterium er- 
füllt ist. 

Bei Screens oder einem 
selbst erstellten Grafikdisplay, 
kann das  Double-Buffering 
Flag »PFBA« genutzt werden. 
Das Display wird im DualPlay- 
field-Modus erstellt (Sie finden 
in diesem Heft auf Seite 66 ei- 
nen Artikel, der sich mit diesem 
View-Modus befaßt). Das zu 
Beginn hintenliegende Play- 
field B dient als Extra-Buffer 
und wird mit der Grafik verse- 
hen. Ist diese aufgebaut, wird in 
der View-Struktur das Flag 
»PFBA« gesetzt und die Cop- 
perlisten neu berechnet, wor- 
aufhin die Playfields die Plätze 
tauschen. Playfield B liegt nun 
vor A und ist demnach sichtbar. 
Der Vorgang wiederholt sich 
mit gedrehten Vorzeichen: das 
unsichtbare Playfield A löschen 
und die neu berechnete Grafik 
darstellen, PFBA-Flag löschen 
und Copperlisten neuberech- 
nen lassen. Dann befinden sich 
die Displays in ihrer ursprüngli- 
chen Lage. Anschaulich wird 
diese Methode, wenn Sie in un- 
serem DualPlayfield-Demoli- 
sting (Seite 66) die zweite if- 
Abfrage innerhalb der while- 
Schleife durch folgende Zeilen 
ersetzen: 
if(ReadStick.ie X)(. 
VPort.Modes-ReadStick. 
ie Х>0 
?DUALPF | PFBA:DUALPF; 
MakeVPort(&View,&VPort); 
MrgCop(&View); 
| 


Nach erfolgreichem Compi- 
lieren können Sie durch Bewe- 
gen des Joysticks іп Y-Richtung 
durch den Speicher »wandern«. 
Bewegen Sie ihn jedoch in X- 
Richtung, werden die Playfields 
vertauscht. Damit ist der Spei- 
cherinhalt im Vordergrund und 
die »Brille« im Hintergrund zu 
sehen. 

Die beschriebenen Double- 
Buffering-Arten sind einfach zu 
realisieren, sie haben aber gra- 
vierende Nachteile. So ist das 
Umschalten der Windows lang- 
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sam und Sie können im Dual- 
Playfield-Modus nur drei Pla- 
nes pro Display aktivieren. Der 
Blitter bietet uns eine Möglich- 
keit, diese Nachteile zu umge- 
hen: Sie initialisieren zwei Buf- 
fer (Windows oder auch ein 
Window und ein RastPort), 
zeichnen auf die unsichtbare 
Zeichenfläche und »clippen« 
das Bild mit der Blitterfunktion 


. ClipBlit() in den Vordergund. 


Die Blitter-Funktion finden Sie 
in unserem Artikel auf Seite 72 
näher erläutert. Diese Technik 
ist für kleinere animierte Grafi- 


Der Blitter 
macht’s 


ken geeignet und nicht kompli- 
zierter zu handhaben als das 
Jonglieren mit Windows. BLTAr- 
row.c (Listing 1) demonstriert 
diese Technik. Das Demopro- 
gramm öffnet zwei »übereinan- 
der« liegende Fenster und be- 
wegt mit der eben beschriebe- 
nen Methode einen dreidi- 
mensionalen »Drahtgitter-Pfeil«. 
Der Clou: Sie können das Ge- 
schehen im Extra-Buffer beob- 
achten, indem Sie das vordere 
Fenster etwas zur Seite schie- 
ben! Obwohl die Grafik nicht 
sehr aufwendig ist, werden so- 
fort alle Vorteile des Double- 
Bufferings klar - die Animation 
auf dem vorderen Window ist 
ruhiger und flüssiger als die an- 
dere. 

Wie funktioniert das Pro- 
gramm? Betrachten. wir die 
Funktion main(). Der Aufruf der 
‚OpenW()-Funktion öffnet alle 
notwendigen Libraries und die 
Fenster. NewDraw() löscht den 
Zeichenbereich des hinteren 
Windows (Window[0]), zeichnet 
den Pfeil und clippt die Zeich- 
nung in das vordere Window. 
Im Rumpf der while-Schleife 
wird, solange das  Close- 
Gadget nicht betátigt wurde, die 
Zeichnung mittels Turn() ge- 
dreht. Turn() berechnet die Posi- 
tionen der Eckpunkte neu und 
ruft die Funktion NewDraw() auf 
- der Kreis ist geschlossen. Clo- 
seW() schließt vor Programm- 
ende alle Ressourcen. 

Mit dieser Methode verlieren 
Sie keine Zeit durch das Wech- 
seln der Windows und die An- 
zahl der Planes wird nicht be- 
eintráchtigt. 

Diese Vorteile bietet auch ei- 
ne kompliziertere Technik, wel- 
che wir als letztes besprechen: 
Double-Buffering mit dem Cop- 
per. Wir benótigen zum Double- 
Buffering zwei getrennte Rast- 
Ports zum Zeichnen und daher 
auch zwei getrennte BitMap- 
Strukturen. Beide BitMaps 


Know-How 


müssen abwechselnd im Vor- 
dergrund sein. Wie wird eine 
BitMap sichtbar? Die View- 
Struktur enthält die Adresse der 
ViewPort-Struktur, diese wie- 
derum verweist auf die Raslnfo- 
Struktur, welche endlich die 
Adresse der BitMap-Struktur 
enthált. Die Funktionen MakeV- 
Port() und MrgCop() erstellen 
die Copperlisten des Diplays. 
LoadView() macht dieses sicht- 
bar. Um zwischen beiden Bit- 
Maps umschalten zu kónnen, 
benótigen wir zwei Copperli- 
sten. Beide Listen müssen eine 
andere BitMap berücksichti- 
gen. Ein Umschalten der Cop- 
perlisten bringt uns den ge- 
wünschten Effekt. Die Adres- 
sen der Copperlisten finden wir 
in der View-Struktur. Wenn Sie 
nicht im Interlace-Modus arbei- 
ten, ist nur View.LOFCprList 
von Interesse. Also los: Wir las- 
sen für die erste BitMap-Struk- 
tur eine Copperliste berechnen. 
Die Adresse der Liste sichern 
wir in einer Variablen. Dann ge- 
ben wir der Rasinfo-Struktur die 
Adresse der anderen BitMap- 
Struktur und lassen eine weite- 
re Copperliste erstellen, ohne 
das Display zu laden. Zuvor 
müssen wir die View-Variable 
LOFOprList (und gegebenen- 
falls auch SHFCprList) auf Null 
setzen, da sich sonst der Amiga 
hartnáckig weigert, eine weite- 
re Liste zu berechnen. Auch die 
Adresse dieser Liste wird gesi- 
chert: 


CList[i]=View.LOFCpr 
List; 


Am besten übernehmen Sie 
beide Adressen in ein Array, so 
können Sie später sehr einfach 
zwischen den Copperlisten um- 
schalten. Jetzt können Sie das 
Display mittels LoadView() 
sichtbar machen. Unsere 
Zeichnung geben wir auf dem 
gerade nicht sichtbaren Rast- 
Port aus: Danach geben wir der 
View-Struktur die Adresse der 
Copperliste bekannt, bei der die 
Rasinfo-Struktur die gleiche 
BitMap-Adresse enthält, des 
gerade benutzten RasPorts: 


View.LOFCprList= 
CList[i]; 


Jetzt laden wir das Display 
mit LoadView(&View). Der Vor- 
gang wiederholt sich: Zeichnen 
auf den verdeckten RastPort, 
die Adressen der Copperlisten 
vertauschen und Aufruf der 
LoadView()-Funktion... 

Das Beispiel »CPRarrow« (Li- 
sting 2) verdeutlicht diesen Pro- 
zeB. Dieses Programm stellt ei- 
nen Pfeil als 3D-Drahtgitter dar, 
allerdings ist er diesmal etwas 


gróBer. Er láBt sich mit dem Joy- 
Stick in jede beliebige Lage dre- 
hen. Das Programm wird mit 
dem Feuerknopf beendet. 
Орепу/д initialisiert in der er- 
sten for-Schleife die beiden 
BitMap- und RastPort-Struktu- 
ren. In der anderen Schleife, 
weiter unten in der Funktion, lö- 
schen wir bei jedem Schleifen- 
durchgang die View-Kompo- 
nente LOFCprList. Eigentlich 
ist dies nur bei jedem zweiten 
Schleifendurchgang nótig. Die 
Rasinfo-Struktur erhält die 
Adresse der ersten BitMap- 
Struktur. Es folgt die Berech- 
nung der ersten Copperliste, 
deren Adresse wir in CList[0] si- 
chern. Beim zweiten Durchlauf 
der Schleife erhält Rasinfo die 
Adresse der zweiten BitMap- 
Struktur. Die Adresse der zwei- 
ten Copperliste wandert nach 
CList[1]. Wir benötigen zum 


CPRarrow zieht 
alle Register 


Umschalten der Listen eine Va- 
riable, die als Index dient: 
CListNr. Die View-Struktur ver- 
weist nach Ende der OpenW()- 
Funktion auf die Liste der in 
CList[1] gesicherten Adresse. 
Da wir auf den verdeckten Rast- 
Port zeichnen möchten, muß 
unsere Index-Variable zu Be- 
ginn den Wert 0 erhalten (Rast- 
Port[0] nicht sichtbar). Nach der 
Initialisierung des Joysticks ruft 
main() die Funktion NewDraw() 
auf. Dort wird mit dem Index der 
Zeichenrastport festgelegt und 
die Zeichnung aufgebaut. Da- 
nach geben wir die Adresse der 
entsprechenden Copperliste 
bekannt (gleicher Index) und la- 
den das Display - die Zeich- 
nung wird sichtbar. Jetzt muB 
für den náchsten Aufruf der 
NewDraw()-Funktion der Index 
umgeschaltet werden. Der be- 
dingte Ausdruck in der letzten 
Zeile von NewDraw() über- 
nimmt diese Aufgabe, er fun- 
giert als Flip-Flop. Die Funktion 
NewDraw() zeichnet beim 
nächsten Aufruf in den ande- 
ren, unsichtbaren RastPort, 
welcher wieder geladen wird, 
Index umschalten etc.... 

Mit diesen vier Double-Buf- 
fering-Verfahren sollten die Zei- 
ten der »Ruckel- und Flimmer- 
grafiken« endgültig vorbei sein. 
Wann ` verbannen Sie das 
Flackern vom Bildschirm? pe 


Arno Gólzer ist ein Mann der ersten Stunde 
und schreibt schon einige Jahre für das AMI- 
GA-Magazin und die AMIGA-Sonderhefte. Sie 
können Ihn erreichen über unsere Verlagsan- 
schrift (Markt&Technik Verlag AG, Redaktion 
Sonderhefte, z. Hd. Herrn Arno Gólzer, Hans- 
Pinsel-StraBe 2, 8013 Haar bei München). 
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/* Aztec C 3.4a 

ес BLTArrow.c +L 

1n BLTArrow.o -1m32 -1¢32 */ 

/* N Gdlzy's > >BLITTER<< Double-Buffering Demo */ 


#include <intuition/intuitionbase.h> 
#include <graphics/gfxmacros.h> 
#include <exec/types.h> 

#include <functions.h> 


#define WIDTH 140 

#define HEIGHT 90 

SHORT Kopf(7]«[ 
4,0,1,2,0,3,4 


D 
SHORT Rumpf [9J={ 
6,7,8,5,9,10,11,12,9 


-30.0,-15.0,-15.0,-15.0,-15.0,-15.0, 
-15.0,-15.0,-15.0,30.0,30.0,30.0,30.0 


j 

FLOAT py[13]={ /* Y-Positionen der Eckpunke des Pfeils */ 
0.0,10.0,10.0,-10.0,-10.0,5.0, 
5.0,-5.0,-5.0,5.0,5.0,-5.0,-5.0 


; 

FLOAT pz[13]-| /% Z-Positionen der Eckpunke des Pfeils X/ 
0.0,10.0,-10.0,-10.0,10.0,5.0, 
-5.0,-5.0,5.0,5.0,-5.0,-5.0,5.0 

; 

struct NewWindow nwin-[ 

60,30, WIDTH, HEIGHT, -1,-1, LOSEWINDOW, O, NULL, NULL, 

(STRPTR) "G61zy's Arrow II^, NULL, NULL, 0,0, 0, 0, WBENCHSCREEN 


struct IntuitionBase *IntuitionBase; 
Struct GfxBase *GfxBase; 

struct MathTransBase *MathTransBase; 
struct Window *win[2]; 

struct RastPort *RP[2]; 

/ж 

\\ Funktionen 

WA 

VOID CloseW() 


[ 
REGISTER SHORT 1; 


for(i=0;i<2;i++) 
if(winfi]) CloseWindow(win[i]); 

if(MathTransBase) CloseLibrary(MathTransBase) ; 
if(GfxBase) CloseLibrary(GfxBase) ; 
if(IntuitionBase) CloseLibrary(IntuitionBase); 
exit(0); 

) 

VOID OpenW() 

[ 
REGISTER SHORT 1; 


if(!(IntuitionBase=(struct IntuitionBase X) 
OpenLibrary(”intuition.library”,0))) Сіовен(); 
if(!(GfxBase=(struct GfxBase *) 
OpenLibrary(”graphies.library”,0))) Сіовем(); 
if(!(MathTransBase=(struct MathTransBase X) 
OpenLibrary(^mathtrans.library",0))) CloseW(); 
Ёог(1=0;1<2;1++)[ 
nwin.Flags=i?ACTIVATEI WINDOWCLOSEI WINDOWDRAG: 0; 
if(!(winfi]=OpenWindow(&nwin))) CloseW(); 
RP[4Jswin[1]->RPort; 
1 
1 
VOID NewDraw() 
{ 
REGISTER SHORT 1,х,у,іпдех; 
SetAPen(RP[0],2); 
RectFill(RP[0],2,10,WIDTH-4,HEIGHT-2); 
SetAPen(RP[0],3); 
Move(RP[0] , 2% (SHORT) px [1] 4WIDTH/2, (SHORT) py [1] &HEIGHT/2) ; 
#ог(1=0;1<7;1++)[ 
index=Kopf[i]; 
x=2% (SHORT) px[index]+WIDTH/2; 
у= (SHORT) py [index] 4HEIGHT/2; 
Draw(RP(0],x,y); 
) 
Move(RP[0] , 2* (SHORT) px[2]+WIDTH/2, (SHORT) py[2] 4HEIGHT/2) ; 
Draw(RP[0] ,2* (SHORT) px(3]+WIDTH/2, (SHORT) py[3]+HEIGHT/2) ; 


; . А 
FLOAT px[13]={ /% X-Positionen der Eckpunke des Pfeils %/ 


Move(RP[0],2*(SHORT) px[5]+WIDTH/2, (SHORT) py [5] 4HEIGHT/2) ; 
for(i=0;i<9;i++){ 

index=Rumpf [i]; 

x-2* (SHORT) px [index ]4WIDTH/2; 

y» (SHORT) py[ index]4HEIGHT/2; 

Draw (RP[0],x,y); 


} 

for(i=0;1<3;i++4){ 
Move(RP[0] ,2* (SHORT) px(6+i]+WIDTH/2, (SHORT) py[6+1]+HEIGHT/2) ; 
Draw(RP[0] ,2* (SHORT) px[10+1]+WIDTH/2, (SHORT) py[10+i]+HEIGHT/2) ; 


} 
ClipBlit(RP[0],2,10,RP[1],2,10,WIDTH-4,HEIGHT-11,0xC0) ; 
} 
VOID Turn(wx,wy) 
FLOAT wx, wy; 
{ 


REGISTER SHORT i; 
FLOAT Xp, yp, ZP, ENN cux, Suy ,cuy; 
swx=sin(wx); _ 
ewxecos(wx) ; 
swy=sin(wy); 
сму=сов(му); 
for(1=0;1<13;i++){ 
yp=py[i]; 
2р=р2[1]; 
ру[1) = yp*cwx+zp*swx; 
pz[i] =-ур*вих+арсых; 
xpepx[1]; 
тр-ра(17; 
px[i] = xpkewy+zpksuy; 
pz[i] s-xp*swyszpXewy; 
) 
NewDraw() ; 
} 
ULONG GetMessage() 
( 
struct IntuiMessage #msg; 
ULONG class=0; 


if(msg=(struct IntuiMessage *)GetMsg(win[1]->UserPort))[ 
class=msg-> Class; 
ReplyMsg(msg) ; 
} 
return(class) ; 
) 
VOID main () 
| 
Орепи() ; 
NewDraw(); 
while (GetMessage()!=CLOSEWINDOW) Turn(.03,.03); 
CloseW() ; 


) 


Listing 1. Double-Buffering mit dem Blitter. Verschiebt 
man das Window, wird der Extra-Buffer sichtbar. 


/* Aztec C 3.48 

cc CPRArrow.c +L 

1n CPRArrow.o -1m32 -1¢32 */ 

/* \\ 0812у!8 >>COPPER<< Double-Buffering Demo */ 


#include <exec/memory.h> 
#include <exec/types.h> 
#include <graphics/gfxbase.n> 
#include <graphics/view.h> 
#include <graphics/copper.h> 
#include <devices/inputevent.h> 
#include <devices/gameport.h> 
#include <functions.h> 


#define WIDTH 320 
#define HEIGHT 256 


SHORT CListNr: 
SHORT Kopf (7) = 

4,0,1,2,0,3,4 
); 


Listing 2. Weiche Animation mit Double-Buffering. 
Dieses Demo arbeitet mit zwei Copperlisten. 
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SHORT Rumpf[9]-[ 
6,7,8,5,9,10,11,12,9 

); 

ULONG GPDev; 

FLOAT px[13]={ /* X-Positionen der Eckpunke des Pfeils %/ 
-120.0,-60.0,-60.0,-60.0,-60.0,-60.0, 
-60.0,-60.0,-60.0,120.0,120.0,120.0,120.0 

1; 

FLOAT py[13]={ /% Y-Positionen der Eckpunke des Pfeils %/ 
0.0,40.0,40.0,-40.0,-40.0,20.0, 
20.0,-20.0,-20.0,20.0,20.0,-20.0,-20.0 

5 

FLOAT pz[13]«[ /* Z-Positionen der Eckpunke des Pfeils %/ 
0.0,40.0,-40.0, -40.0,40.0,20.0, 
-20.0,-20.0,20.0,20.0,-20.0,-20.0,20.0 

із 

struct GamePortTrigger GPTrigger=[ 

GPTF_UPKEYSI GPTF_DOWNKEYS,0,1, 1 

li 

struct GfxBase *GfxBase; 

struct View *01dView, View; 

struct cprlist *CList[2]; 

struct MsgPort *GPort; 

struct IOStdReq *GPRequest; 

struct MathTransBase *MathTransBase; 

struct InputEvent ReadStick; 

struct ViewPort VPort; 

struct RasInfo RasInfo; 

struct BitMap BMap(2]; 

struct RastPort RP(2],*RPort; 


/ж 
\\ Funktionen 
%/ 


VOID CloseW() 


( 
REGISTER SHORT 1; 


if(OldView)( 

LoadView(OldView) ; 

WaitTOF(); 
] 
FreeVPortCopLists(&VPort); 
for(i=0;1<2;i++)  FreeCprList(CList[1]); 
if(VPort.ColorMap) ^ FreeColorMap(VPort.ColorMap); 
for(is0;i<2;iH) . 

if(BMap(1].Planes[0]) ` 

FreeRaster(BMap[1].Planes[0], WIDTH, HEIGHT) ; 
if(GPDev) CloseDevice(GPRequest) ; 
if(GPRequest) DeleteStdIO(GPRequest); 
if(GPort) DeletePort(GPort) ; 
if(MathTransBase) CloseLibrary(MathTransBase) ; 
if(GfxBase) CloseLibrary(GfxBase) ; 
exit(0); 
| 


VOID OpenW() 
[ 


REGISTER SHORT 1; 


if(!(GfxBase=(struct GfxBase X) 
OpenLibrary("graphies.library",0)))  CloseW(); 

if(!(MathTransBase=(struct MathTransBase X) 
OpenLibrary("mathtrans.library",0)))  CloseW(); 

if(!(GPort=CreatePort( ”GPort”,0))) C1oseW(); 

1f(1(GPRequestsCreateStdIO(GPort))) CloseW(); 

if(GPDev=(ULONG) 
OpenDevice("gameport.device",1,GPRequest,0)) CloseW(); 

OldView=GfxBase~>ActiView; 

InitView(&View); 

InitVPort(&VPort); 

Ёог(1=0;1<2;1++)[ 
InitRastPort(&RP[i]); 
InitBitMap(&BMap[1],1,WIDTH,HEIOHT); 
if(!(BMap[i].Planes[0]=(PLANEPTR) 

AllocRaster(WIDTH;HEIGHT)))  CloseW(); 

RP[1].BitMapc&BMap[1]; 

} 

View.ViewPort =&VPort; 

VPort.DWidth =WIDTH; 

VPort.DHeight =HEICHT; 

VPort.RasInfo =&RasInfo; 

VPort.ColorMap =GetColorMap(2); 
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Know-How 


RasInfo.Rx0ffset=0; 
RasInfo.RyOffset=0; 
RasInfo.Next =NULL; 


for(i=0;1<2;i++){ /% zwei LOF-Copperlisten berechnen lassen %/ 


View.LOFCprList=NULL; 
RasInfo.BitMap=&BMap[i]; 
MakeVPort(&View, &VPort) ; 
MrgCop(&View) ; 
CList[1]=View.LOFCprList; 
} 
} 


VOID SetGPRequest(doit,c,1,d) 
BOOL doit; 
UWORD е; 
ULONG 1; 
APTR dj 


GPRequest-» io Command =c; 
GPRequest->io_Length =1; 
GPRequest->io_Data =d; 
if(doit) DoIO(GPRequest); 


] 


VOID InitStick() 
( 
UBYTE Data=GPCT_RELJOYSTICK; 
ULONG 1gssizeof(struct GamePortTrigger), 
lissizeof(struct InputEvent); 


SetGPRequest(1,GPD_SETCTYPE,1,&Data); 

SetGPRequest(1,GPD_SETTRIGGER, 1g, &GPTrigger); 

SetGPRequest (0, GPD. READEVENT, 11 , &ReadStick) ; 
) 


VOID NewDraw() 
REGISTER SHORT 1,x,y, index; 


RPort=&RP[CListNr]; /% Zeichenrastport festlegen %/ 
SetRast(RPort,0) ; 
Move(RPort, (SHORT) px (1]160, (SHORT)py[1]+128) ; 
for(1-0;1«7;1-«)[ 
index=Kopf[i]; 
x=(SHORT)px[index]+160; 
y=(SHORT)py[index]+128; 
Draw(RPort,x,y); 
) 
Move (RPort, (SHORT) px[2]+160, (SHORT)py[2]+128) ; 
Draw (RPort, (SHORT) px[3]+160, (SHORT)py[3]+128) ; 
Move (RPort, (SHORT) px[5]+160, (SHORT) py[5]+128) ; 
for(1=0;1<9;1++){ 
index=Rumpf [4]; 
x= (SHORT) px[index]+160; 
у= (SHORT) py [index] +128; 
Draw(RPort,x,y); 
] 
for(i=0;1<3;1++)[ 
Move(RPort, (SHORT) px[6+1]+160, (SHORT) py[6+1]+128) ; 
Draw(RPort, (SHORT)px[10+1]+160, (SHORT) py[10+1]+128) ; 
} 


View.LOFCprList=CList[CListNr]; /% Copperlisten tauschen */ 


LoadView(&View) ; 
OListNr-CListNr?0:1; 


) 


VOID Turn(wx, wy) 
FLOAT wx, wy; 
( 


REGISTER SHORT 1; 
FLOAT xp,yp,2p,Swx,cwx,swy,cwy; 


swx=sin(wx) ; 
ewx=cos(wx) ; 
swy=sin(wy) ; 
ewy=cos(wy) ; 
for(i=0;i<13;i++)( 
Ур=ру[1]; 
zpzpz[1]; 
ру[1] = yp*ewxezp*swx; 
pz[i] =-yp*swx+zp*ewx; 


Listing 2. (Fortsetzung) 


xp=px[i]; 
2р=р2[1]; 
рх[1] = xpkewy+zpksuy; 
pz[i] =-xpksuy+zpkeuy; 


) 


NewDraw() ; 


} 


VOID main () 

( 
UBYTE Data=GPCT_NOCONTROLLER; 
FLOAT w1,w2; 


Openk(); 
InitStick(); 
NewDraw(); 


Bit 


Von Arno Gölzer 


it dem »BLock Image 
TransfER«, besser 
bekannt unter dem Na- 


men »Blitter«, stehen dem Spie- 
leprogrammierer alle Türen of- 
fen. Dabei ist es nicht einmal 
notwendig, sich mit der Hard- 
ware auseinanderzusetzen. Das 
Betriebssystem spricht die Blit- 
terfunktionen effektiv genug an. 
Der Chip, mit dem wohlklin- 
genden Namen Agnus, vereint 
unter anderem die beiden Co- 
prozessoren Copper und Blitter. 
Die Haupt- und Lieblingsaufga- 
be des Blitters ist das Kopieren 
von Daten, wobei er die Kopie 
gleichzeitig durch die Verknüp- 
fung mit anderen Speicherbe- 
reichen manipulieren kann. 
Darüber hinaus füllt er mit 
atemberaubender Geschwin- 
digkeit Flächen und zeichnet 
ebenso schnell Linien auf die 
Zeichenfläche vor den Augen 
des staunenden Amiga-Users. 
Wegen dieser Eigenschaften 
und ob seiner rasanten Arbeits- 
geschwindigkeit, findet der Blit- 
ter immer dort, wo es um 
schnelle Grafik geht, seinen 
Einsatz. Der Coprozessor kann 
direkt über die Hardware-Regi- 
ster (siehe im Artikel über den 
»Copper« auf Seite 84 - Listing 
1) manipuliert und gestartet 
werden. Wir möchten jedoch 
hier die speziellen Systemrouti- 
nen der Graphics-Library näher 
beleuchten, die den Blitter ver- 
anlassen, Speicherbereiche zu 
kopieren. Beachten Sie hierbei, 
daß die Höhe und die Breite des 
Kopierbereichs 1024 Pixel nicht 
überschreiten darf. 
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while(1){ 
SendIO(GPRequest) ; 
WaitIO(GPRequest); 
else[ 
else w2-.0; 
else ч1-.0; 
Turn(wi,w2) ; 
) 
) 


CloseW(); 


] 
Listing 2. (Schluß) 


Schneller kopieren mit dem Blitter 


if(ReadStick.ie Codes-IECODE LBUTTON) 


Zu jedem Spiel gehórt einfach eine gute 
Grafik - und schnell muß sie natürlich 
auch sein. Der Amiga hat interessante Fä- 
higkeiten mit überraschendem Tempo auf 
Lager. Der Blitter macht's möglich. 


Bevorzugte Aufgabe des Blit- 
ters ist es, Daten durch den 
Speicher zu jagen. Nach dem 
Test der ersten Funktion, die wir 
Ihnen vorstellen móchten, wer- 
den Sie diese Neigung verste- 
hen und vor allem nutzen: Clip- 

Blit(&von,x1,y1,&nach,x2,y2,b, 
h,m) ermöglicht das Kopieren 
eines rechteckigen Bereiches 
von RastPort »von« nach Rast- 
Port »nach«, in einer wahrhaft 
atemberaubenden Geschwin- 
digkeit. Die linke obere Ecke 
des Quellrechtecks befindet 
sich ап der Position x1/y1 im 
RastPort »von«. 

Das Rechteck ist »b« Pixel 
breit und »h« Pixel hoch. Clip- 
Blit() kopiert es so, daß sich des- 
sen linke Ecke nach dem Clip 
an der Position x2/y2, im Rast- 
Port »nach« befindet. Natürlich 
kónnen Sie für beide RastPorts 
auch die gleiche Adresse ange- 
ben. 

Für diese Funktion haben wir 
auch gleich ein Demo-Listing 
vorbereitet: »BBrush.c« (Listing 
1) Nach dem Start des Pro- 
gramms kónnen Sie, in einer 


speziell angelegten Zeichenflä- 
che, mit einem Ausschnitt des 
beim Aufruf gerade aktiven 
Windows zeichnen. Bei der Be- 
tátigung der linken Maustaste 
wird bei jeder Mausbewegung 
der Quellbereich unverändert 
in den Zielbereich kopiert. Mit 
Druck auf die rechte Taste er- 
scheint jedoch das kopierte 
Rechteck invertiert. 

Wir haben die Möglichkeit 
der Veränderung des Kopierbe- 
reichs durch eine logische Ver- 
knüpfung mit dem Zielbereich 
genutzt. Die Art der Verknüp- 
fung teilen wir dem Blitter über 
den letzten Parameter der Clip- 
Blit-Funktion »m« mit. 

Die UBYTE-Variable »m« 
Steht für Minterm. Tabelle 1 
zeigt: mit den oberen 4 Bit ist 
die Verknüpfungsart codiert. 
Nehmen wir das einfachste Bei- 
spiel: der Wert 0x80 als Min- 
term ergibt als Ergebnis Rast- 
Port V (von) AND RastPort N 
(nach). Das heiBt, nur wo in bei- 
den RastPorts Punkte gesetzt 
sind, ist nach der Verknüpfung 
auch wirklich ein Punkt zu se- 


Verknüpfung | Minterm | 


00010000 = 0х10 


00100000 - 0х20 
01000000 - 0х40 
00010000 - 0х80 


Tabelle 1. Mit Minterms werden Daten verknüpft 


break; 


if(ReadStick.ie X) w2=ReadStick.ie_X>0?-.03:.03; 


if(ReadStick.ie Y) wi-ReadStick.ie Y» 0?-.03:.03; 


SetGPRequest(1,GPD. SETCTYPE, 1, &Data) ; 


‚Schnelle Grafik 


hen. Ein weiteres Beispiel, 
diesmal mit einem Minterm- 
Wert von 0х40. Der Blitter setzt 
einen Punkt, wenn in V eben- 
falls ein Punkt, aber in N kein 
Punkt gesetzt war. 

Die Verknüpfung erfolgt Bit- 
Plane für BitPlane. Die Farbe 
richtet sich nach dem Inhalt des 
Farbregisters mit der Nummer 
des neuen Wertes (siehe Bild 
1). Alle in unserer Tabelle 1 auf- 
geführten Minterms können 
des weiteren noch untereinan- 
der mit OR verknüpft werden. 
Bei den vier möglichen Bits gibt 
es 2*=16 Verknüpfungsmög- 
lichkeiten. Wieder einige Bei- 
spiele: 

(1V&IN) I (1V&N) 

Die Werte Ox10 und 0x20 
wurden mit ODER zu 0x30 ver- 
knüpft. Der obige Ausdruck läßt 
Sich noch vereinfachen, indem 
man »!V« ausklammert: 
ІМЕ(ІМІ N)21V 

Der Klammerausdruck »IN | 
N« wird zu 1 und wir erhalten 
demnach als Ergebnis »!V&1«, 
was »!У« entspricht. Der Wert 
0x30 invertiert demnach den 
Bereich in RastPort V und legt 
ihn in RastPort N ab. So wurde 
auch die  Invertierung in 
BBrush.c (Listing 1) erreicht. 
Welche Auswirkung hat der 
Wert 0xC0? Um diesen Wert zu 
erreichen, müssen wir 0x80 
und 0x40 mit ODER verknüp- 
fen: 

(VEN) | (V&IN) =V 

Hier wird der Quellbereich 
ohne Veránderung übernom- 
men. Nehmen Sie sich doch 
das Programm Brush vor und 
testen Sie einmal alle 16 Min- 
terms durch! Wenn Sie die Ein- 
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gabe von Kommandoparame- 
tern erlauben, wird die Aufgabe 
besonders einfach. Testen Sie 
dann gleich einmal Minterm 
0x60. Er veranlaßt den Blitter, 
beide RastPorts mit EOR zu 
verknüpfen, das heißt nur. an 
den Stellen werden Punkte ge- 
setzt, wo entweder in V oder in 
N ein Punkt gesetzt war. Zwei- 
maliges Blitten mit gleichen Pa- 
rametern stellt den ursprüngli- 
chen Zustand wieder her. In 
Spielen wird diese Möglichkeit 
oft für die unterschiedlichsten 
Effekte genutzt, z.B. wird mit 
dieser Technik im Spiel Reflex 
(in diesem Heft auf Seite 6) eine 
»Explosion« dargestellt. 
ClipBlit() blittet von RastPort 
zu RastPort. Wagen wir uns 
noch eine Ebene tiefer und ar- 
beiten mit BitMaps, denn oft ist 
es nicht notwendig, einen kom- 
plett initialisierten RastPort im 
Arbeitsspeicher mitzuschlep- 
pen. In vielen Fällen, z.B. für 
den »UNDO«-Buffer in Zeichen- 
programmen, reichen Informa- 
tionen über die Lage des Spei- 
cherplatzes für die einzelnen 
BitPlanes und deren Größe 
aus. Diese Informationen sind 
in der BitMap-Struktur - Listing 
2 zeigt sie nocheinmal - zusam- 
mengefaßt. Hier die Initialisie- 
rung und die Freigabe einer 
BitMap-Struktur namens BM: 


struct BitMap BM; 


InitBitMap(&BM,p,b,h); 
for(i=0;i<p;it+){ 
BM.Planes[i]= 
(PLANEPTR)AllocRaster 
(b,h))); 
if(BM.Planes[i]) 
BltClear 
(BM.Planes[i],RASSIZE 
(5,h),1); 

else quit(); 

) 

quit() 

| 

for(i=0;i<p;i++)[ 
if(BM.Planes[i]) Free- 
Raster(BM.Planes 

Ze b,h); 


Mit der InitBitMap()-Funktion 
legen Sie fest, wie viele Planen 
(p) von der Größe b+h (Brei- 
te*Hóhe) Pixel Sie benötigen. 
Die Funktion AllocRaster reser- 
viert den notwendigen Spei- 
cherplatz im Chipmemory. Als 
Rückgabewert erhalten Sie die 
Adresse der Plane oder - falls 
ein Fehler auftrat - »NULL«. 
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dem Bildschirm fest 


Die Blitter-Funktion BltClear 
() lóscht Plane, auf die mittels 
des ersten Parameters verwie- 
sen wurde. Die notwendige 
GróBe errechnet das im Hea- 
derfile »graphics/gfx.h« defi- 
nierte Makro »RASSIZE()«. Der 
dritte Parameter ist ein Flag mit 
folgender Bedeutung: ist Bit 1 
gesetzt, deutet die Funktion die 
oberen 16 Bits des zweiten Pa- 
rameters (hier RASSIZE(w,h) 
als die Anzahl der zu lóschen- 
den Zeilen und die unter 16 Bits 
als die Anzahl der zu lóschen- 
den Bytes pro Zeile - ein Recht- 
eck wird gelóscht. Ist jedoch Bit 
1 gelöscht; so interpretiert 
BitClear() den zweiten Parame- 
ter als die tatsáchliche Anzahl 
der zu lóschenden Bytes. Setzt 
man Bit 0 auf eins, wartet das 
Programm, bis der Blitter mit 
Lóschen fertig ist. 

In unserem Beispiel gibt 
demnach der zweite Parameter 
die Anzahl der Bytes an, die in 
der BitPlane gelóscht werden 
sollen. Dabei wartet das Pro- 
gramm so lange, bis der Blitter 
seine Arbeit verrichtet hat. 

Es versteht sich von selbst, 
daß der disziplinierte Program- 
mierer die reservierten BitPla- 
nes vor Programmende wieder 
freigibt. Hier geschieht das mit 
FreeRaster(. Parameter sind 
neben der Adresse der Plane, 
deren Breite und Hóhe. Das wa- 
ren die Vorbereitungen, nun zur 
Anwendung: 


Bild 1. Die Bitebenen legen die Farben eines Punktes auf 


Know-How 


Forbregister | 


struct BitMap von,nach; 
SHORT x1,y1,x2,y2,b,h; 
UBYTE m,M; 
PLANEPTR t; 


BltBitMap(&von,x1,y1,& 
nach,x2,y2,b,h,m,M,t); 


Diese riesige Anzahl von ak- 
tuellen Parametern sind not- 
wendig, um ein Rechteck von 
einer BitMap in die andere zu 
blitten. Aber keine Angst, die 
Funktion ist der vorher bespro- 
chenen sehr ähnlich. Die Para- 
meter »von« und »nach« sind 
diesmal die Adressen der bei- 
den BitMaps. Auch hier können 
beide gleich sein, nur müssen 
wir in diesem Fall Platz für ei- 
nen Zwischenspeicher schaf- 
fen, falls sich die Bereiche 
überschneiden. Dieser Zwi- 
schenspeicher könnte z.B. ein 
temporäres Raster sein, wel- 
ches man für die Area- oder die 
Füll-Funktionen angelegt hat. 
Er muß nur groß genug sein, 
um den überlappenden Be- 
reich aufnehmen zu können. 

Der letzte Parameter, im Bei- 
spiel »t«, verweist auf den Zwi- 
schenspeicher. Das große M im 
Aufruf steht für Maske. Hiermit 
geben Sie an, welche BitPla- 
ne(s) die Funktion blitten soll. 
Für jede Plane müssen Sie ein 
Bit setzen, wobei die Nummer 
der Plane in der BitMap-Struk- 
tur gleich dem Bit in Maske ist. 


Setzen Sie also Bit 0 und 1, 
wenn Sie möchten, daß die Pla- 
nes 0 und 1 geblittet werden 
sollen. Ansonsten entsprechen 
die Parameter denen der be- 
reits besprochenen ClipBlit()- 
Funktion. 

Eine Funktion, die von einem 
RastPort in eine BitMap kopiert, 
existiert nicht. Vielleicht fällt Ih- 
nen eine ein? Denken Sie dabei 
an die einzelnen Komponenten 
der RastPort-Struktur - findet 
man da nicht die Adresse der 
BitMap-Struktur? 

Das Kopieren aus einer Bit- 
Map in einen RastPort ist dage- 
gen bereits móglich: BItBitMap- 
RastPort(&von,x1,y1,&nach,x2, 
y2,b,h,m). Die Adresse »von« ist 
die Quell-BitMap und »nach« 
die des Ziel-RastPorts. Alle an- 
deren Parameter können Sie 
von den vorangegangenen 
Funktionen übernehmen. Die 
folgende Funktion kopiert 
ebenfalls ein Rechteck aus ei- 
ner Quell-BitMap in einen Ziel- 
RastPort. Dabei kann der Be- 
reich nicht nur durch die Min- 
terms manipuliert werden, son- 
dern noch durch eine zusätzli- 
che Bitplane, die als Maske 
oder »Sieb« fungiert: 
BltMaskBitMapRastPort(& 
von,x1,y1,&nach,x2,y2,b, 
h,m,&p); 


Sie sehen, der Aufruf unter- 
scheidet sich von dem der Bit- 
BitMapRastPort()-Funktion nur 
durch den zusätzlichen Para- 
meter »p«. Er steht für die 
Adresse der Sieb-Plane. An 
den Stellen, wo die Punkte des 
Siebes gesetzt sind, ist er für 
den Quellbereich durchlässig. 
An gelóschten Stellen ist dage- 
gen kein Durchkommen. 

Ganz áhnlich funktioniert Blt- 
Pattern(&rp,&p,xa,ya,xe,ye,n). 
Die Funktion zeichnet ein 
Rechteck »durch eine Maske« 
auf RastPort »rp«. Gesetzte Far- 
ben, der Zeichenmodus und 
Pattern werden dabei aus der 
RastPort-Struktur übernom- 

men. 

Die Maske ist wieder, wie bei 
BitMaskBitMapRastPort() be- 
schrieben, eine einzelne Bit- 
Plane. Wir nennen Sie im Bei- 
spiel»p«. Diese Plane ist für das 
Rechteck an den gelöschten 
Plane-Punkten durchlässig. 

Die linke obere Ecke des 
Rechtecks liegt an der Position 
xalya, die rechte untere Ecke 
bei xe/ye. Parameter »n« gibt 
den BytesPerRow-Wert der Ma- 
sken-Plane an. Sie kennen die- 
se Bezeichnung aus der Bit- 
Map-Struktur. Ist Ihre Sieb- 
Plane z.B. 640 Pixel breit, so er- 
rechnet sich der entsprechende 
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BytesPerRow-Wert aus 640/8 
= 80 Byte. 

Ersetzen Sie, zur Verdeutli- 
chung, die ClipBlit(-Funktion 
aus unserem Demo-Listing 1 
durch die folgende Zeile: 


BltPattern(RPW,RPA- 
>BitMap->Planes[0], 
ХРоѕ,у,ХРоѕ+64,у+32,80); 


Wir benutzen die erste Plane 
des Workbench-Screens als 
Sieb. Da sie im Hires-Modus ei- 
ne Breite von 640 Pixeln mißt, 
geben wir als BytesPerRow-Wert 
80 an. Das Rechteck soll 64 
Punkte breit und 32 Punkte hoch 
sein. Beim Zeichnen scheint 
das Rechteck nur an den Stel- 
len durch, wo in Plane 0 Punkte 
gesetzt sind. Sie können das 
Rechteck durch das Setzen von 
Zeichenfarbe, -modus und -mu- 
ster beliebig verändern. 

Die letzte Funktion unseres 
Blitter-Exkurses kopiert eben- 
falls Daten. Es handelt sich 
aber diesmal um gepackte Da- 
ten, wie etwa die Zeichen aus 
den Amiga-Fonts. Die Zeichen 
werden im Speicher so dicht 
aneinandergereiht, daß keine 
Bitspalte Platz zwischen ihnen 
findet. 


APTR von; 

struct RastPort xnach; 
SHORT pos,mod,x,y,b,h; 
BltTemplate(von,pos,mod, 
nach,x,y,b,h); 


/* 
ce BBrush.c +L 
1n BBrush.o -1¢32 


\\ G8lzy's Blitter-Brush.c 
WA 


BitTemplate() liest diese ge- 
packten Zeichen ab der Spei- 
cherstelle »von« und schreibt 
sie an der Position x/y in den 
RastPort »nach«. Der Parame- 
ter »pos« gibt dabei an, an wel- 
cher Bit-Position der Quellbe- 
reich, in unserem Beispiel das 
Zeichen, zu finden ist. Die Brei- 
te des Speicherbereichs, in 
dem die Daten gepackt unter- 
gebracht sind, gibt der »mod«- 
Wert (für »Modulo«) in Byte an. 
Die restlichen beiden Parame- 
ter b und h stehen für die Breite 
und die Hóhe des Rechtecks. 

Vor dem Aufruf von BltTem- 
plate() können Sie die Zeichen- 
farbe und den Zeichenmodus 
beliebig einstellen. Beachten 
Sie bitte beim Experimentieren, 
daB der Blitter nur Daten aus 
dem Chip-Memory lesen kann. 
Über den Blitter gábe es noch 
vieles zu berichten - vermutlich 
kónnte man mit einer ausführli- 
chen Beschreibung fast ein ei- 
genes Sonderheft füllen. In 
dem vorliegenden Heft finden 
Sie noch einen Artikel, der sich 
mit dieser Materie befaBt, es 
geht dort um die für die Spiele- 
programmierung wichtigen 
BOBs - die »Blitter Objects«. 

so 


Arno Gólzer ist ein Mann der ersten Stunde. 
Seit über zwei Jahren arbeitet er als Autor für 
AMIGA-Magazin und AMIGA-Sonderhefte. Sie 
können ihn erreichen über unsere Verlagsan- 
schrift (Markt & Technik Verlag AG, Redaktion 
Sonderhefte, z. Hd. Herrn Arno Gólzer, Hans- 
Pinsel-Stra&e 2, 8013 Haar bei München). 


#include <intuition/intuitionbase.h> 


#include <ехес/пепогу.һ> 
#include <exec/types.h> 
#include <functions.h> 


#define KEYDOWN ((code==SELECTDOWN)|| (codes -MENUDOWN) ) 


#define RPA (awin->RPort) 
#define RPW (win->RPort) 

#define ХРов (win->MouseX) 
#define YPos (win->MouseY) 


struct NewWindow nwin={ 


0,40,640,216, -1,-1, CLOSEWINDOW! MOUSEMOVEI MOUSEBUTTONS , 
REPORTMOUSEI RMBTRAPI WINDOWCLOSEI ACTIVATE, 
NULL,NULL, (STRPTR) ”0812у!8 Blitter-Brush”, 


р 
struct IntuitionBase 
struct GfxBase 
struct Window 


VOID CloseW() 

( 
if(win) 
if(GfxBase) 
if(IntuitionBase) ` 


NULL, NULL, 0,0,0,0,WBENCHSCREEN 


*IntuitionBase; 
*GfxBase; 
*win,*awin; 


CloseWindow(win) ; 
CloseLibrary(GfxBase) ; 
CloseLibrary(IntuitionBase) ; 


VOID OpenW() 
{ 


REGISTER SHORT 1; 


if(!(IntuitionBase=(struct IntuitionBase X) 
OpenLibrary(^intuition.library",0))) 
awin=(struct Window *) IntuitionBase->ActiveWindow; 
if(!(GfxBase=(struct GfxBase *) 
OpenLibrary("graphics.library",0))) CloseW(); 
4£(!(win=OpenWindow(&nwin))) CloseW(); 


CloseW(); 


) 


ULONG GetMessage(code) 
USHORT *code; 
( 


struct IntuiMessage #msg; 
ULONG class=0; 


if(msg=(struct IntuiMessage *)GetMsg(win->UserPort))[ 
class=msg- >Class; 
*code=msg->Code; 
ReplyMsg(msg) ; 

} 


return(class) ; 


] 


VOID DrawBrush(mt) 


[ 


UBYTE nt; 


ULONG class; 
USHORT code; 
SHORT y,keyup=0; 


while(!keyup){ 
WaitPort(win->UserPort) ; 
while(class=GetMessage(&code) ){ 
if((code==SELECTUP)I| (code==MENUUP)) keyup=1; 
if(class==MOUSEMOVE){ 
y=YPos; 
if(y>10) ClipBlit(RPA,0,0,RPW,XPos, 
y,80,40,mt) ; 


] 


VOID main() 
{ 


ULONG class=0; 
USHORT code,quit=0; 


Орепи() ; 
vhile(!quit)[ 
WaitPort(win->UserPort) ; 
while (class=GetMessage(&code))[ 
if( (elass==MOUSEBUTTONS) &&KEYDOWN) 
DrawBrush( (codes -SELECTDOWN) ?0x00:0x- 


else if(class==CLOSEWINDOW) quit=1; 
} 
} 


CloseW() ; 


Listing 1. Blitter macht’s möglich: Zeichnen mit 
dem Teil eines RastPorts als Brush! 


struct BitMap 

І 
UWORD BytesPerRow;./* Bytes pro BitMap-Zeile (Breite/8) %/ 
UWORD Rows; /* Anzahl der Zeilen (Höhe) */ 
UBYTE Flags; /* 22? -- vermutlich ungenutzt */ 
UBYTE Depth; /* Anzahl der BitPlanen (BitEbenen) */ 
UWORD pad; /* Platzhalter -- PLANEPTR beginnen auf LONGWORD */ 
PLANEPTR Planes[8]; /* Adressen der BitEbenen im Speicher %/ 


Із 


Listing 2. Die BitMap-Struktur verwaltet elementare 
Daten über den Bildschirminhalt 
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Know-How 


Joystick-Abfrage für Ihre Programme 


Kein Joy ohne Stick 


ollen Sie auf dem 
Bildschirm zeichnen, 
ist die Maus ein idea- 


les Eingabegerät. Wenn es 
aber darum geht, ein Auto ge- 
schickt über einen Parcours zu 
steuern oder ein Männchen 
durch ein Labyrinth zu führen, 
ist der Joystick einfach nicht zu 
ersetzen. Schließlich ist er dazu 
bestimmt, seine Mikroschalter 
in Action-Games zu verschlei- 
Ben. 

Sie entscheiden sich also, in 
Ihrem neuesten Amiga-Game 
dem Joystick den Vorzug zu ge- 
ben. Aber sofort stellt sich ein 
Problem: wie frágt man diesen 
Knüppel.ab? 

Eine Kontrollmóglichkeit ist 
das ständige Auslesen der 
Hardware-Register »joyOdat« 
(OxDFFOOA) für den linken Port 
und »joyldat« (OXDFFOOC) für 
den rechten Port. Diese Technik 
eignet sich jedoch für Program- 
me in einer Multitasking-Umge- 
bung nicht sehr gut, da sie das 
System nur unnötig belastet. 

Wir gehen besser den siche- 
ren Weg über das Betriebssy- 
Stem und kontrollieren den Joy- 
Stick über das GamePort-Devi- 
ce. Der erste Schritt dazu ist 
das Öffnen des Devices mit der 
Exec-Funktion 
OpenDevice(name,unr,req, 
flags) 

Die Parameter der Funktion 
sind: 

name: der Gerätename als 
nullterminierte Zeichenkette, in 
unserem Fall »gameport.de- 
Vice« 5 

unr: die Gerätenummer (0 für 
den linken und 1 für den rech- 
ten Game-Port) 

ioreq: die Adresse einer 
»lOStdReg«-Struktur 

flags: bei der Verwendung 
des GamePort-Device werden 
keine Flags angegeben. 

Die Funktion liefert den 
»ULONG«-Wert 0, wenn das 
Gerät ordnungsgemäß geöffnet 
werden konnte. Allerdings muß 
die »lOStdReq«-Struktur be- 
reits mit einigen Werten ver- 
sorgt sein. Diese Aufgabe über- 
nehmen die beiden Support- 
Routinen »CreatePort(pname, 
pri)« und »CreateStdlO(port)«. 

»CreatePort« verlangt als Pa- 
rameter die Zeichenkette »pna- 
me« und die Priorität »pri«. Die- 
se Funktion liefert bei fehlerfrei- 
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Die Maus als Eingabegerät am Amiga ist 
eine fantastische Sache. Aber bei Spielen 
kann sie den guten alten Joystick nicht er- 
setzen. Wir zeigen Ihnen eine einfache 
Methode der Joystick-Abfrage. 


Von Arno Gölzer 


em Lauf als Ergebnis die Adres- 
se des generierten »Message«- 
Ports. Sie dient als Parameter 
für die zweite Funktion: »Crea- 
teStdlO()« Diese legt die Re- 
quest-Struktur an und liefert - 
falls alles geklappt hat - die 
Adresse der Struktur. Treten 
Fehler auf, liefern beide Funk- 
tionen 0. 

Für unser Beispiel verwen- 
den wir Game-Port 2, da dieser 
frei ist. Darüber hinaus ist Port 1 
im Normalfall schon vom Input- 
Device zur Abfrage der Maus 
belegt. Somit gestaltet sich der 
Aufruf wie folgt: 


TEXT Name[]=”gameport. 
device”; 

ULONG Error; 

struct MsgPortxMPort; 
struct IOStdReqxIOReq; 


MPort=CreatePort 
("Мате 70) ; 
if(MPort==NULL) ... / 
x Error x/ 
I10Req=CreateStd10 
(MPort) ; 
if(IOReq--NULL) ... / 
x Error x/- 


- Error=OpenDevice 


(Мапе,1,10Веа4,0); 
if(Error) ... /x Error x/ 


Liefert »OpenDevice« keinen 
Fehler, so ist der rechte Game- 
Port bereit, unsere Wünsche, 
im Form vordefinierter Kom- 
mandos, zu empfangen. Diese 
sind im Headerfile »devices/ga- 
meport.h« vereinbart. Wir un- 
terscheiden fünf verschiedene 
Kommandos: 

GPD ASKCTYPE: Clype 
(Typ des aktuellen Controllers; 
Siehe unten) erfragen 

GPD__SETCTYPE: 
festlegen 

GPD__ASKTRIGGER: erfra- 
gen der Bedingungen in Form 
der »GamePortTrigger«-Struk- 
tur (Listing 1) 


Clype 


GPD__SETTRIGGER: die 
Mitteilung der Testbedingun- 
gen mit Hilfe der eben genann- 
ten Struktur 

GPD__READEVENT: 
die GamePort-Meldungen. 

Zu Beginn unserer Arbeit 
sollten Sie testen, ob Ihnen 
»GamePort-Device« tatsächlich 
zur Verfügung steht: 


UBYTE d; 


liest 


IOReg- > io_Command= 
GPD_ASKTRIGGER 

IOReq- io Length -1; 
IOReq-te Data -&d; 

if (DoIO(IOReq)!=0) .../ 
x Error x/ 
if(d!=GPCT_NOCON- 
TROLLER) ... /x Error x/ 


Nur wenn die über das Data- 
Byte empfangene Meldung be- 
sagt, daß bislang kein »Control- 
ler« angemeldet wurde, kann 
das Device die Überwachungs- 
arbeit des Joysticks oder der 
Maus übernehmen. Wir unter- 
scheiden folgende Controller- 
Typen: 

GPCT__ALLOCATED: Game- 
Port ist bereits von einem ande- 
ren Task belegt 

GPCT. NOCONTROLLER: 
GamePort ist noch frei 

GPCT. MOUSE: die Maus 
als Controller 

ОРСТ. RELJOYSTICK: Joy- 
stick als Controller, GamePort- 
Device meldet die Joystick- 
Richtung stándig 

GPCT__ABSJOYSTICK: Joy- 
Stick als Controller, GamePort- 
Device meldet die Joystick- 
Richtung nur bei einer Rich- 
tungsánderung 

Der náchste Schritt ist die 
Festlegung des eigenen Con- 
trollertyps mit dem Kommando 
»GPD__SETCTYPE«. Dazu 
kann wieder eine Sequenz, 
ähnlich der oben angeführten, 
dienen. Diesmal ist jedoch der 
»io. Command Type« gleich 
»GPD__SETCTYPE« und die 


Data-Komponente erwartet die 

Adresse eines Byte mit dem 

Controllertyp als Wert. Dazu ein 

Beispiel: 

UBYTE d=GPCT_ABS- 
JOYSTICK; 


Möchten Sie dem System Ih- 
re eigenen Testbedingungen 
mitteilen, so wiederholen Sie 
die Sequenz ein weiteres Mal. 
Das Kommando lautet dann 
»GPD__SETTRIGGER«. Das 
Data-Feld verlangt nun die 
Adresse der »GamePortTrig- 
ger«-Struktur. Die Datenlänge 
in Bytes errechnen Sie am be- 
sten mit dem Operator 


sizeof(struct 
GamePort-Trigger) 


Die »GamePortTrigger«-Struk- 
tur (Listing 1) muß bis dahin be- 
reits beschrieben sein. Hier die 
einzelnen Komponenten dieser 
kurzen Struktur: 

gpt Keys: gibt an, ob das 
Betátigen oder das Loslassen 
des Feuerknopfes (oder der 
Maustasten beim Controller 
»GPCT. MOUSE« gemeldet 
werden soll. Hierfür stehen 
zwei Flags zur Verfügung: 
»GPTF_UPKEYS« veranlaßt 
eine Meldung bei Betátigung 
und »GPTF__DOWNKEYS« 
läßt das Loslassen des Buttons 
signalisieren. Natürlich können 
Sie beide Flags mit »ODER« 
verknüpfen, wenn Sie alle zwei 
Meldungen empfangen möch- 
ten. 

өрі Timeout: die Zeit zwi- 
schen zwei »ReadEvents« in 
Tics (1/50 Sekunden). 

gpt_XDelta und орі  YDel- 
ta: »Weg« zwischen zwei »Read- 
Events« in Impulsen, die durch 
die Lochscheibe in der Maus 
erzeugt werden (in X/Y-Rich- 
tung). 

Zum Schluß bereiten wir die 
»lOStdReq«-Struktur noch mit- 
tels des Kommandos »GPD. . 
READEVENT« vor. Als Datum 
übergeben wir die Adresse der 
InputEvent-Struktur. Nach je- 
dem Start des Kommandos mit 
»DolO()« oder auch »SendlO()« 
(gefolgt von »WaitlO()« oder 
»WaitPort()«), kann die »Input- 
Event«-Struktur ausgelesen 
und so die Joystick-Stellung er- 
mittelt werden. 

Allerdings liefert die Struktur 
keine absoluten Werte, sondern 
lediglich die Richtung des 
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Sticks. Beinhaltet die »Input- 
Event«-Strukturkomponente 
»ie.X« einen negativen Wert, so 
befindet sich der Joystick an 
seinem linken Anschlag. Ist der 
Wert positiv, wird er gerade 
nach rechts gedrückt. Das Ele- 
ment »ieY« zeigt die vertikale 
Position an. Ein negativer Wert 
bedeutet, daB der Joystick in 
Richtung Monitor bewegt 

wurde. 
Die Betätigung des Buttons 


ermitteln wir über die Kompo-' 


nente »ie__Code«. Es existieren 
folgende Flags (s. auch Header- 
file »devices/inputevent.h«): 

IECODE LBUTTON: linker 
Mausknopf oder Feuerknopf 
des Joysticks 

IECODE .RBUTTON: rech- 
ter Mausknopf 

IECODE_MBUTTON: 
(noch) nicht existierender mitt- 
lerer Mausknopf 

IECODE_NOBUTTON: we- 
der Maustaste noch Feuer- 
knopf wurden betätigt 

IECODE UP. PREFIX: Die- 
ses Flag ist mit einem der drei 
zuerst beschriebenen mit 
»ODER« verknüpft und zeigt 
an,.daß der Knopf losgelassen 
wurde. 

Vor Programmende muß der 
Game-Port auf »GPCT. NO- 
CONTROLLER« eingestellt 
und der reservierte Speicher 
freigegeben werden. Die Frei- 
gabe erfolgt mit den Funktio- 
nen: 


CloseDevice(IOReq) ; 
DeleteStdIO(IOReq); 
DeletePort(MPort); 


Unser kleines Beispiellisting 
(Listing 2) soll Sie etwas zum 
Experimentieren anregen. Wir 
testen darin auf »ABSJOY- 
STICK«, geben Sie aber ruhig 
einmal andere Controller an. 
Die Funktion »OpenW()« öffnet 
uns neben den Libraries und 
dem Window auch das Game- 
Port-Device. Die Initialisierung 
des Joysticks erfolgt durch die 


struct GamePortTrigger [ 
UWORD gpt. Keys; 
UWORD gpt_Timeout; 
UWORD gpt_XDelta; 
UWORD gpt_YDelta; 
р 


Funktionen »InitStick()« und 
»SetGPRequest()«. Diese über- 
nehmen Prüfung und Festle- 
gung des Controller-Typs und 
der Testbedingungen und tref- 
fen außerdem die Vorbereitun- 
gen zum Starten der »Read- 
Events«. 

In der Hauptfunktion »main()« 
erfolgt, mittels einer Endlos- 
schleife, der eigentliche Start 
mit »SendlO()« und »WaitlO()«. 
Entsprechend den Bewegungen 
des Joysticks - wir testen die 
ankommenden »InputEvents« 
ebenfalls in der while-Endlos- 
schleife - zeichnet »DrawC()« 
eine Kreisfläche in unser 
Demo-Window. Nach der Betä- 
tigung des Feuerknopfs - wir er- 
warten gemäß der »GamePort- 
Trigger«-Struktur die Betäti- 
gung und das Loslassen des 
Knopfes - erfolgt das Pro- 
grammende. 

Dies erfolgt selbstverständ- 
lich nicht, ohne das Device auf 
»GPCT_NOCONTROLLER« 
zu schalten und den in »Open- 
W(« allokierten Speicher mit- 
tels deren Gegenstück »Close- 

W()« wieder freizugeben. 

Wir hoffen, Ihnen mit diesem 
Beitrag den Einstieg in die 
Spieleprogrammierung mit Joy- 
stick erleichtert zu haben. Sie 
werden in den weiteren Artikeln 
der Rubrik »Know-how« immer 
wieder auf Teile des beschrie- 
benen Beispielprogramms sto- 
Ben. Allerdings haben wir dort 
auf den Test mit »ASKCTYPE« 
verzichtet, da wir davon ausge- 
hen, daB Sie sich beim Auste- 
sten der Demos nicht gleichzei- 
tig mit Ihrem Flugsimulator im 
siebenten Himmel befinden. 

Martin Jobst/so 


Arno Gólzer ist ein Mann der ersten Stunde 
und schreibt schon einige Jahre für das 
AMIGA-Magazin und die AMIGA-Sonderhefte. 
Sie können ihn erreichen über unsere Verlags- 
anschrift (Markt A Technik Verlag AG, Redak- 
tion Sonderhefte, z. Hd. Arno Gölzer, Hans- 
Pinsel-Straße 2, 8013 Haar bei München). 


Listing 1. Die »GamePortTrigger«-Struktur 
legt fest, in welcher Weise ein Joystick oder 
die Maus getestet werden sollen 


/* 
ce Stick.e +L 
In Stick.o -1¢32 
%/ 

/* 


AA Géólzy's JoyStick-Demo 

*/ 4 
#include <intuition/intuitionbase.h> 
#include <graphies/gfxbase.h> 
#include <exec/memory.h> 

#include <exec/types.h> 

#include <devices/inputevent.h> 
#include <devices/gameport.h> 
#include <functions.h> 


#define TMPDIM 100 


TEXT DName[]=" Gölzy's JoyStick-Demo”; 

WORD Buffer[10]; 

ULONG GPDev; 

struct GamePortTrigger GPTrigger-[ 
GPTF. UPKEYSI GPTF. DOWNKEYS, 0,1, 1 


NewWindow hwin={ 
0,0,400,210,0,1,0, ACTIVATE, NULL, NULL, 
DName, NULL,NULL,0,0,0,0, WBENCHSCREEN 

Із 

struct IntuitionBase *IntuitionBase; 

struct GfxBase *GfxBase; 

struct Window win; 

struct RastPort “RP; 

struct MsgPort *GPort; " 

struct IOStdReq *GPRequest; 

struct InputEvent ReadStick; 

struct TmpRas Raster; 

struct AreaInfo AInfo; 

PLANEPTR Bitplane; 


HI 
\\ Funktionen 
Mé 


VOID CloseW() 

( 
1f(Bitplane) 
if(GPDev) 
if(GPRequest) 
if(GPort) 
if(win) 
if (GfxBase) 
if(IntuitionBase) 
exit(0); 


FreeRaster(Bitplane, TMPDIM, TMPDIM) ; 
CloseDevice(GPRequest); 
DeleteStdIO(GPRequest); 
DeletePort(GPort); 

CloseWindow(win) ; 
CloseLibrary(GfxBase) ; 
CloseLibrary(IntuitionBase) ; 


) 


VOID OpenW() 
[ 
if(!(IntuitionBase=(struct IntuitionBase *) 
OpenLibrary("intuition.library",0))) 
if(!(GfxBase=(struct GfxBase X) 
OpenLibrary("graphics.library",0))) CloseW(); 
if(! (win=OpenWindow(&nwin))) CloseW(); 
RP=win->RPort; 
if(!(GPort=CreatePort( ”GPort”,0))) 
1f(!(GPRequestsCreateStdIO(GPort))) 
if(GPDev=(ULONG) 
OpenDevice("gameport.device",1,GPRequest,0)) CloseW( 


C1oseW(); 


CloseW() 5 
C1oseW(); 


if(!(Bitplane=AllocRaster(TMPDIM, TMPDIM) ) ) Сіовен(); 
InitTmpRas(&Raster,Bitplane,RASSIZE(TMPDIM, TMPDIM) ) ; 
InitArea(&AInfo, Buffer, 2) ; 

RP-» TmpRas =&Raster; 

RP->Arealnfo =&AInfo; 


) 


LONG SetGPRequest(doit,command,length,data) 
BOOL doit; 
UWORD command; 
ULONG length; 
APTR data; 


GPRequest-- 1o Command =command; 
СРВедџеѕ+- > io Length -length; 
GPRequest- io. Data zdata; 
if(doit) return(DoIO(GPRequest)); 
else return(0); 
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VOID InitStick() 


{ 


UBYTE Check,Data=GPCT_ABSJOYSTICK; 


ULONG 


lg=sizeof(struct GamePortTrigger) , 


li=sizeof(struct InputEvent) ; 


if(SetGPRequest(1,GPD_ASKCTYPE, 1, &Check) ) 
if (Check! =GPCT_NOCONTROLLER) 
1f (SetGPRequest(1,GPD_SETCTYPE, 1, &Data) ) 


CloseW(); 
CloseW(); 
CloseW(); 


if(SetGPRequest (1,GPD_SETTRIGGER, 1g, &GPTrigger))CloseW(); 
SetGPRequest(0,GPD_READEVENT, 1i, &ReadStick) ; 


) 


VOID DrawC(x,y,r) 
SHORT x,y,r; 
{ 


AreaEllipse(RP,x,y,2*r,r); 


AreaEnd(RP); 
] 


VOID DrawPic() 
{ 
REGISTER SHORT 1,),1; 


SetDrMd(RP, JAM2) ; 
Ёот(1#0;1<2;1++)[ 
SetAPen(RP,2-1) ; 


RectFill(RP,10«(4*1),15«(2*1),390- (4*1),205-(241)); 


] 
for(1-0;1« 3; 1) 


for(j=0;J<3; JH) [ 


Ғог(1-0;1<2;1--)| 
SetAPen(RP,2-1*2); 
DrawC(10041*100,604.]450,25-2*1) ; 


Know-How 


SetDrMd(RP,JAM1I COMPLEMENT) ; 


DrawC(200, 110,20) ; 
) 


VOID main () 


( 


UBYTE Data=GPCT_NOCONTROLLER; 


SHORT x-200,y-110; 


Орепм(); 
DrawPic(); 
InitStick(); 
while(1){ 


SendIO(GPRequest) ; 
WaitIO(GPRequest); 


DrawC(x,y,20); 


if(ReadStick.ie Code--IECODE LBUTTON) break; 


if(ReadStick.ie_X)[ 
if(ReadStick.ie_X<0) 


else 


] 
else x=200; 


if(ReadStick.ie_Y)[ 


x=100; 
x=300; 


if(ReadStick.ie_Y<0) у= 60; 


else 
] 
else y=110; 
DrawC(x,y,20) ; 


) 


y=160; 


SetGPRequest(1,GPD_SETCTYPE, 1, &Data) ; 


C1oseW(); 
) 


Listing 2. Unser Joystick-Demoprogramm 
überwacht über »GamePort«-Device 
einen »ABS«-Joystick 


Animationen mit Superbitmaps 


. Grafik am laufenden Band 


ine Móglichkeit, Bewe- 

gungen auf den Bild- 

schirm zu bringen, ist 
die Definition übergroBer Bit- 
Maps, den sogenannten Super- 
BitMaps (nicht zu verwechseln 
mit SuperBigMacs). Es handelt 
sich um BitPlanes, die größer 
sind als das Display in dem sie 
dargestellt werden. Intuition 
stellt uns mit dem SuperBitMap- 
Window ein vorgefertigtes Ele- 
ment zur Verfügung, welches 
die Arbeit mit großen BitPlanes 
erlaubt. Da Intuition bei Spielen 
meist nicht benötigt wird, befas- 
sen wir uns in diesem Artikel mit 
einfachen. Grafikdisplays, um 
zu sehen, welche Möglichkei- 
ten uns hier offenstehen. 

Wir initialisieren die View-, 
ViewPort- und BitMap-Struktur, 
lassen die Copperlisten be- 
rechnen und starten das Dis- 
play. Die genaue Vorgehens- 
weise für die Definition eines ei- 
genen Views finden Sie in die- 
sem Heft (Seite 81) im Artikel 
»Intuition ausgebremst«. Die 
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Ist es nicht faszinierend, wenn in einem 

Spiel aufwendige Grafiken wie ein endlo- 

ses Band in einer atemberaubenden Ge- 

schwindigkeit über den Bildschirm scrol- 

len? Fragen Sie sich auch jedesmal, wie 

das möglich ist? Dieser Artikel gibt die 
Antwort auf Ihre Fragen! 


BitPlanes sollen diesmal je- 
doch größer sein, als der View- 
Port. Die Ausmaße einer Bit- 
Map ist nur vom zur Verfügung 
stehenden Chip-Memory ab- 
hängig. Leider ist dieser Spei- 
cherbereich mit seinen 512 
KByte nicht allzu groß bemes- 
sen, so daß die Vorausberech- 
nung des benötigten Speichers 
sicherlich sinnvoll ist. Der Spei- 
cherbedarf einer BitMap oder 
allgemein eines Bildschirms 
(Screens) wächst proportional 
mit der Anzahl der gewünsch- 
ten Punkte (Auflösung) und pro- 
portional mit der Anzahl der Bit- 


ebenen (Farben). Berechnen 
wir als Beispiel einen Bild- 
schirm im Hires-Interlace-Mo- 
dus. Ein solcher Bildschirm ar- 
beitet mit einer Auflösung von 
640 x 512 Pixel. Angenommen 
wir benötigen die maximale An- 
zahl von Farben in diesem Mo- 
dus und fordern entsprechend 
vier Planes an. Dann errechnet 
sich der benötigte Speicher- 
platz wie folgt: 


Memory= (640x512) Punktex 
4Bitebenen/8=163840Byte 


In Tabelle 1 finden Sie den 
Bedarf an Chipmemory, der mit 


fünf Planes móglichen Display- 
modis. Die BitMaps kónnen je- 
doch noch wesentlich gróBer 
sein als die DisplaygróBen in 
der Tabelle. Das Beispielpro- 
gramm »SuperBitMap.c« (Li- 
sting 1) fordert zwei Planes mit 
einer Größe von 200 x 2000 Pi- 
xel, was nach obenstehender 
Rechnung etwa 100 KByte des 
(Chip-)Arbeitsspeichers »kostet«! 

Sind alle Vorbereitungen ge- 
troffen und das neue Display 
geladen, ist nur ein Ausschnitt 
der gesamten BitMap im View- 
Port sichtbar (Bild 1). Das Scrol- 
ling erreichen Sie durch konti- 
nuierliches Verschieben der 
Riesenplanes »unter dem View- 
Port-Ausschnitt«. Die Kompo- 
nenten RxOffset und RyOffset 
der Raslnfo-Struktur beschrei- 
ben die X/Y-Koordinate des 
Punktes im Raster, welcher an 
der linken oberen Ecke des 
ViewPorts dargestellt. werden 
soll. Andern wir diese Varia- 
blen, so ándert sich, nach der 
Neuberechnung der Copperli- 
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Bitebenen Farben 


Ound 1 
Obis 3 
Obis 7 
0 bis 15 
0 bis 31 


Farbreg. 


320x256 320х 512 
10240 
20480 
30720 
40960 
51200 


20480 
40960 
61440 
81920 
102400 


Tabelle 1. SuperBitMaps sind sehr speicherintensiv 


sten, die Position der BitMap im 
ViewPort-Fenster. Inkrementie- 
ren wir beispielsweise den X- 
Offset, so rollt das Raster nach 
links aus dem ViewPort, da die 
an der linken oberen Ecke des 
ViewPorts dargestellten Positio- 
nen weiter nach rechts im Ra- 
ster wandern. Stellen Sie sich 
einfach ein Blatt Papier vor, das 
Sie unter einer Lupe verschie- 
ben. Skalieren Sie das Blatt am 
oberen Rand von links nach 
rechts aufsteigend. Bewegen 
Sie das Blatt unter der Lupe, 
daß sich an der linken oberen 
Ecke der Lupe immer höhere 
Werte der Skala befinden. Sie 
müssen dazu das Blatt nach 
links (oder die Lupe nach 
rechts) bewegen. Möchten Sie, 
daß das Raster nach oben wan- 
dert, müssen Sie, da sich der 
Ursprung des Bildschirmkoor- 
dinatensystems in der linken 
oberen Monitorecke befindet, 
die Y-Position in RasInfo-Struk- 
tur ebenfalls erhöhen. Die Bit- 
Map-Struktur enthält die wah- 
ren Ausmaße des Rasters, wäh- 
rend in den ViewPort-Struktur- 
Variablen DWidth und DHeight 
die Maße des dargestellten 
Ausschnitts gespeichert sind. 

Die Positionen, an denen ein 
Raster gerade noch dargestellt 
werden kann, sozusagen die 
Extrem-Werte der Rasinfo-Va- 
riablen, errechnen sich wie 
folgt: 


X-Position 
X-Position 


min - 0 

max = Breite- 
DWidth 

тіп - 0 

max = Höhe- 
DHeight 


Y-Position 
Y-Position 


Diese Werte müssen im Pro- 
gramm abgefragt werden. Läuft 
das Raster nach einer Richtung 
aus dem Display, erscheint dort 
der Inhalt des Arbeitsspeichers 
als Grafik, was besonders beim 
Verschieben in. Y-Richtung 
eher merkwürdig aussieht. Was 
noch fehlt ist die Berechnung 
der CopperListen zur Darstel- 
lung. der veränderten Position 
des Rasters im ViewPort. Hier- 
zu dient die Funktion 


SerollVPort(&ViewPort); 


Als Parameter verlangt sie 
die Adresse des ViewPorts. 
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Nach dem Einfügen der Funk- 
tion prásentiert sich das Raster 
an der neuen Position. Sowohl 
die Scroll-Richtung als auch die 
Scroll-Geschwindigkeit richten 
Sich nach dem Inkrement der 
Rastinfo-Variablen RxOffset 
und RyOffset. Sie legen damit 
fest, wie viele Pixel das Raster 
in der jeweiligen Richtung ver- 
schoben werden soll. Erhöhen 
Sie beispielsweise in einer 
Schleife die Offsets X und Y bei 
jedem Durchgang um 10, so be- 
wegt sich das Raster bei jedem 
Aufruf der ScrollVPort()-Funk- 
tion um 10 Pixel nach links und 


640 x 256 


640x512 Punkte 


20480 
40960 
61440 
81920 


40960 
81920 
122880 
163840 


de beliebige Richtung gelenkt 
werden. Bewegungen des 
Steuerknüppels in Y-Richtung 
beschleunigen bzw. bremsen 
das Fahrzeug. Sollte man trotz 
aller Vorsicht dennoch mit ei- 
nem Hindernis kollidieren, läßt 
sich das Fahrzeug am leichte- 
sten in X-Richtung aus dem 
»Gestrüpp« abschleppen. Es 
fällt gar nicht auf, daß sich das 
Fahrzeug nicht bewegt, son- 
dern die Landschaft unter dem 
Auto hinweg gezogen wird. 

In der gegenwärtigen Version, 
des Betriebssystems kann der 
Workbenchscreen mit der Ta- 


Bild 1. Nur ein Teil der BitMap wird im ViewPort sichtbar 


oben. Wenn Sie in jedem Schlei- 
fendurchgang den Wert 1 ad- 
dieren, erscheint die Bewe- 
gung wesentlich langsamer. 
Diese Móglichkeit der Steue- 
rung von Geschwindigkeit und 
Richtung des Rasters im Dis- 
play haben wir auch in unserem 
SuperBitMap-Demo genutzt. 
Es handelt sich um ein kleines 
Spiel oder besser formuliert, 
um den Grundstock eines 
Spiels. Der Spieler soll einen 
sportlich rasanten Flitzer ge- 
schickt um die Bäume und Be- 
pflanzungen einer der belieb- 
ten verkehrsberuhigten Stra- 
Ben lenken. Sollten Sie mit Bäu- 
men oder dem Bordstein zu- 
sammenstoßen, blitzt der Bild- 
schirm, in Vertretung des Ge- 
setzeshüters, mahnend auf. 
Der Wagen wird mit dem Joy- 
stick in Game-Port 2 gesteuert. 
Der Feuerknopf beendet das 
Spiel. Das Fahrzeug kann in je- 


stenkombination <Linke Ami- 
ga n> nach vorne gebracht 
werden. Da wir nicht mit einem 
Screen arbeiten, kann das Dis- 
play nicht mehr vor die Work- 
bench geklappt werden. Abhilfe 
schafft ein Aufruf der Load- 
View()-Funktion, worauf im De- 
mo verzichtet wurde. 

Bevor Sie mit dem Demoli- 
sting experimentieren, bespre- 
chen wir den Quellcode des 
Programms. Die Funktion 
OpenW() übernimmt vorberei- 
tende Maßnahmen für den Pro- 
grammablauf. Zu Beginn be- 
sorgt sie die Basisadresse der 
Grafik-Library, rettet die Adres- 
se der aktuellen View-Struktur 
und kopiert die Sprite-Daten für 
den Wagen ins Chip-Memory. 
Danach óffnet sie das Game- 
Port-Device für den Port 2 (Pa- 
rameter 2 == 1 für Port 2; == 
0 für Port 1). AllocRaster() be- 
sorgt uns ein BitPlane für ein 


Temporár-Raster, welches wir 
spáter bei der Verwendung der 
Area-Funktionen benötigen. 
Jetzt werden die Strukturen für 
das Grafikdisplay initialisiert. 
Wir fordern dabei eine Color- 
Map mit 24 Farben an. Die er- 
Sten vier Farben (da zwei Bit- 
Planes) brauchen wir zur Dar- 
stellung des Spielfeldes, die 
letzten drei sind die Farben des 
Auto-Sprites. 

Das Ende der OpenW()-Funk- 
tion bilden die Aufrufe der Be- 
triebssystem-Funktionen zur 
Berechnung der Copperlisten. 
Die Funktion CloseW() schließt 
alle erhaltenen Ressourcen in 
umgekehrter Reihenfolge. Auch 
die Copperlisten müssen frei- 
gegeben werden, was vielleicht 
nicht so einfach einzusehen ist, 
da der Speicher dafür nicht ex- 
plizit angefordert wurde. 

InitStick() gibt dem GamePort- 
Device bekannt, daß die Abfra- 
ge eines. Joysticks verlangt 
wird. Danach zeichnet Draw- 
VP() das Spielfeld mit Sprite. 
Beachten Sie, daß .sich die 
Sprite-Position nicht auf den 
ViewPort, sondern auf den 
View bezieht. In DrawVP() wird 
auch das neue Display mit 
LoadView() dargestellt. Doch 
zuvor teilen wir dem Hardware- 
Register »clxcon« (0x98) mit, 
daß wir bei Kollisionen mit Far- 
ben, die in Plane 0 ein Bit set- 
zen, eine Meldung wünschen. 
Es handelt sich dabei um die 
Farben 1 und 3, mit denen der 
StraBenrand und die Báume 
gezeichnet sind. 

Im Headerfile hardware/cu- 
stom.h sind die Register der 
Custom-Chips, die sich ab 
Adresse OxDFF000 im Spei- 
cher befinden, als Custom- 
Struktur vereint und namentlich 
festgehalten. Die Kollisionsmel- 
dung erscheint spáter im Regi- 
ster »clxdat« (OxOE). Ist das 
Spielfeld sichtbar, verlangt der 
Aufruf »CreateProcFunktion()« 
den Start der Funktion MSpeed() 
als eigenen Prozeß. Diese 
Funktion ist im Heft 11 des AMI- 
GA-Magazins ausführlich be- 
schrieben, so daB wir auf eine 
Erklárung an dieser Stelle ver- 
zichten kónnen. Wichtig ist nur, 
zu wissen, daB durch diesen 
Aufruf die Funktion MSpeed() 
quasi parallel zum Hauptpro- 
gramm läuft (Aztec C-Anwen- 
der bitte an die geta4()-Funktion 
denken!). MSpeed() hat die Auf- 
gabe, stándig den Bildschirm in 
Y-Richtung zu verschieben und 
das Register clxdat zu überwa- 
chen. 

Als Inkrement der Y-Offsets 
der Rasinfo-Struktur dient uns 
die Variable »Speed«, welche 
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sich bei der Betätigung des Joy- 
sticks in Y-Richtung ändert. Be- 
achten Sie, daß wir die Bewe- 
gung an den Extremwerten für 
RyOffset (0 und MAXH) nicht 
stoppen, sondern auf das an- 
dere Extrem umschalten. Da- 
durch entsteht eine geschlos- 
sene Schleife - Grafik am lau- 
fenden Band! Stellt MSpeed() 
einen Crash fest, so wird die 


Hintergrundfarbe kurz rot ge- 
färbt. In der Hauptfunktion 
main() überwachen wir in einer 
while-Schleife den Game-Port. 
Empfangen wir eine Meldung 
über eine Joystick-Bewegung 
in X-Richtung, scrollen wir das 
Raster pixelweise in die ge- 
wünschte Richtung, jedoch ma- 
ximal bis zum Extremwert. 
Drückt der Spieler den Feuer- 


Know-How 


button, so erfüllen wir das 
Schleifenkriterium der while- 
Schleife (Quit = 1) und been- 
den mit CloseW() das Pro- 
gramm. 

SuperBitMap.c ist natürlich 
kein ausgereiftes Spiel, aber es 
zeigt doch mit seinen knapp 
300 Zeilen, was ohne großen 
Aufwand zu erreichen ist. Viel- 


eine neue Idee, bei der die be- 
schriebene Technik zum Ein- 
satz kommt? Also los - wir wol- 
len Sie nicht aufhalten! pe 


Arno Gölzer ist ein Mann der ersten Stunde 
und schreibt schon einige Jahre für das AMI- 
GA-Magazin und die AMIGA-Sonderhefte. Sie 
können ihn erreichen über unsere Verlagsan- 
schrift (Markt & Technik Verlag AG, Redaktion 
‚Sonderhefte, z. Hd. Herrn Gölzer, Hans-Pinsel- 
StraBe 2, 8013 Haar bei München). 


leicht haben Sie ja auch schon 


/* Aztec C 3.48 

сс SBM.c +L 

1n SBM.o -1032 */ 

/* N Gdlzy's SuperBitMap.c X/ 


Vë 


struct Process KCreateFunetionProc(name,pri,function,stacksize) 
STRPTR name; 
LONG pri,stacksize; 
#include <exec/memory.h> VOID (*funetion)(); 
#include <exec/types.h> 
#include <graphics/gfxbase.h> 
#include <graphics/sprite.h> 
#include <graphics/view.h> 
#include <devices/inputevent.h> 
#include <devices/gameport.h> 
#include <hardware/custom.h> 
#include <functions.h> 


struct MsgPort *mport; 
struct Process *proc; 
struct HelpSeg{ 
LONG Len,Next; 
WORD OCode; 
VOID (XFAddr)(); 
| *HSeg; 


#define SDATA 36 

#define TMPDIM 200 

#define DWIDTH 100 

#define DHEIGHT 200 

#define WIDTH 200 

#define HEIGHT 2000 

#define MAXW — (WIDTH-DWIDTH) 
#define МАХН · (HEIGHT-DHEIGHT) 


if(!(HSeg=(struct HelpSeg %) 

AllocMem(sizeof(struct HelpSeg),MEMF PUBLIC))) return(NULL); 
HSeg->Len =sizeof(struct HelpSeg); 

HSeg->Next =0; 
HSeg->0Code =0x4EF9; 

HSeg->FAddr =funetion; 

mport=(struct MsgPort *) 

CreateProc(name,pri, (LONG) (&(HSeg->Next)) > >2,stacksize) ; 
proc=(struct Process*) ((ULONG)mport-(ULONG)sizeof(struct Task) ); 
while(!FindTask(name)); 

FreeMen(HSeg,sizeof(struct HelpSeg)); 
return(proc) ; 


VOID MSpeed(); 

BOOL Quit=FALSE; 

SHORT SNr=-1,Speed=0, Inc=0; 

USHORT *SAuto,SData[SDATA]=[ 
0,0, 
0x07E0 ,0x0000, 0x0000, 0x0FFO,0x1008,0x1FF8,0x1008,0x1FF8, 
0х1308,0х1038,0х03С0,0х0С30,0х07Е0,0х0810,0х07Е0,0х0810, 
0х17Е8,0х1818,0х17Е8,0х1818,0х17Е8,0х1818,0х0000,0х0ҒҒ0, 
0x0000, 0x0420, 0x0000, OxOFFO , OXOFFO , 0x0000 , 0x0000 , 0x030 , 
0,0 


) 


VOID CloseW() 


( 
REGISTER SHORT 1; 


if(SNr>0) FreeSprite(SNr); 

if(01àView)[ 
LoadView(0ldView); 
WaitTOF(); 


; я 

WORD Buffer[10],001Tab[24]=[ 
OXFFF,OxAC6, OXDDD, OXFCB , 
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 
OXFEC, OxF00,0 


} 
FreeVPortCopLists(&VPort) ; 
FreeCprList(View.LOFCprList) ; 
if(VPort.ColorMap) FreeColorMap(VPort.ColorMap); 
for(4=0;1<2;4++){ 
1f(BMap.Planes[1]) 
FreeRaster(BMap.Planes[i],WIDTH,HEIGHT); 


; 
UWORD Pattern[2][8]=[ 
0х1111,0х2222,0х4444,0х8888,0х1111,0х2222,0х4444,0х8888, 
0x0C0C,0xCCC0,0x3333,0x3333,0x0CCC, OXCCCC , 0x3333 ,0x3333 


ULONG GPDev; 
struct SimpleSprite Auto=[ 
NULL, 16,0,0,2 


} 
if(Bitplane) 
if(GPDev) 

if (GPRequest) 
if(GPort) 
if(SAuto) 
if(GfxBase) 
exit(0); 


FreeRaster(Bitplane,TMPDIM,TMPDIM); 
CloseDevice(GPRequest) ; 
DeleteStdIO(GPRequest); 
DeletePort(GPort); 
FreeMen(SAuto,SDATAX2) ; 
CloseLibrary(GfxBase) ; 


struct GamePortTrigger GPTrigger=( 
GPTF_UPKEYSI GPTF_DOWNKEYS,0,1, 1 
H 
struct GfxBase 
struct Process 
struct View 
struct MsgPort 
struct IOStdReq 
struct InputEvent 
struct ViewPort 
struct RasInfo RasInfo; 
struct BitMap BMap; 
struct RastPort RP; 
struct TmpRas Raster; 
struct Arealnfo AInfo; 
PLANEPTR Bitplane; 


*GfxBase; 
*Process; 
*01dView, View; 
*GPort; 
*GPRequest; 
ReadStick; 
VPort; 


] 


VOID OpenW() 
( 


REGISTER SHORT 1; 


if(!(GfxBase=(struct GfxBase X) 
OpenLibrary(”graphics.library”,0))) 
OldView=GfxBase->ActiView; 
if(!(SAuto=(USHORT *)AllocMem(SDATA*2,MEMF_CHIP))) CloseW(); 
CopyMem(SData,SAuto,SDATA*2) ; 
Auto.posetldata=SAuto; 
if(!(GPort=CreatePort(”GPort”,0))) 
if(1(GPRequest=CreateStdI0(GPort))) 
if (GPDev=(ULONG) 
OpenDevice("gameport.device",1,GPRequest,0)) CloseW(); 


CloseW(); 


CloseW(); 
CloseW(); 

/ж 

\\ Funktionen 
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if(!(Bitplane=AllocRaster(TMPDIM,TMPDIM))) Сіовен(); 

InitView(&View) ; 

InitVPort(&VPort); 

InitRastPort(&RP) ; 

InitTmpRas(&Raster,Bitplane,RASSIZE(TMPDIM, TMPDIM) ) ; 

InitArea(&AInfo,Buffer,2); 

InitBitMap(&BMap,2,WIDTH, HEIGHT) ; 

for(1:0;1<2;14)( 
if(!(BMap.Planes[1]=(PLANEPTR)AllocRaster(WIDTH,HEICHT))) 
CloseW(); 
BltClear(BMap.Planes[1],RASSIZE(WIDTH,HEIGHT),0); 

) 

View.ViewPort =&VPort; 

View.Modes =SPRITES; 

VPort.Modes =SPRITES; 

VPort.DWidth =DWIDTH; 

VPort.DHeight =DHEIGHT; 

VPort.DxOffset =160-DWIDTH/2; 

VPort.DyOffset ^ -128-DHEIGHT/2; 

VPort.RasInfo =&RasInfo; 

VPort.ColorMap -бе%Со1огМар(24); 

RasInfo.BitMap =&ВМар; 

RasInfo.Rx0ffset=50; 

RasInfo.RyOffset=MAXH; 

RasInfo.Next =NULL; 

RP.BitMap =&BMap; 

RP.TmpRas =&Raster; 

RP.AreaInfo — -&AInfo; 

LoadRGB4 (&VPort , ColTab , 24) ; 

MakeVPort (&View,&VPort); 

MrgCop(&View); 

] 


VOID DrawC(x,y,r) 
SHORT x,y,r; 

{ 
AreaEllipse(&RP,x,y,r,r); 
AreaEnd(&RP) ; 


) 


VOID DrawVP() 


[ 
REGISTER SHORT 1,y,v; 


SetAPen(&RP,2) ; 

Ғог(1=0;1<10;1++) 
RectFi11(&RP,50,1X200,150, (1+1)%200-1); 

SetAPen(&RP,0); 

Ғог(1і-0;1<2000;1%-20)| 
RectFill(&RP,98,1,102,1+15) ; 


SetAPen(&RP, 3) ; 

SetAfPt(&RP,Pattern[0],3); 

for(1-0;1« 10; 1—)[ 
RectFill(&RP, 0,1%200, 49, (1+1)*200-1) 
RectFill(&RP,151,1%200,200, (1+1)*200-1) 


H 


) 
SetAPen(&RP,1); 
SetAfPt(&RP,Pattern[1],3); 
for(1=0;1< 10; i++){ 
y224041*160; 
т-(10-1)6; 
Dra«C(50,y,r); 
DrawC(150,y480,7); 
DrawC(100,1100+1*70, 141); 
) 
SNr=GetSprite(&Auto,2); 
MoveSprite(&VPort,&Auto, 152,185); 
eustom.clxcon=(UWORD)Ox41; 
LoadView(&View) ; 


] 


LONG SetGPRequest(doit,c,1,d) 
BOOL doit; 
UWORD e; 
ULONG 1; 
APTR d; 


LONG error-0; 


GPRequest-»1io Command =c; 


GPRequest-- io Length =1; 
GPRequest-»1io Data =d; 
if(doit) error=DoI0(GPRequest) ; 
return(error) ; 


VOID InitStick() 

{ 
UBYTE Data=GPCT_RELJOYSTICK; 
ULONG 1gssizeof(struct GamePortTrigger) , 

lissizeof(struct InputEvent) ; 

if(SetGPRequest(1,GPD_SETCTYPE,1,&Data)) С1овен(); 
if (SetGPRequest(1,GPD_SETTRIGGER, 1g, &GPTrigger) )CloseW(); 
SetGPRequest (0,GPD_READEVENT, 11 , &ReadStick) ; 

) 


VOID main () 

{ 
UBYTE Data=GPCT_NOCONTROLLER; 
SHORT x=50; 


Орепи() ; 
InitStick(); 
DrawVP(); 
if(!(Process=CreateFunctionProc( "MSpeed”,0,MSpeed,4000))) 
CloseW(); 
while(!Quit){ ` 
SendIO(GPRequest) ; $ 
WaitI0(GPRequest) ; d 
if(ReadStick.ie Codes-IECODE LBUTTON) Quit=TRUE; ` 
else{ 
if(ReadStick.i1e.X)[ 
x+=ReadStick.ie_X<0?-1:1; 
Af(x>MAXW) х=МАХИ; 
if(x«0) x20; 
RasInfo.Rx0ffset=x; 
WaitTOF(); 
ScrollVPort(&VPort) ; 
] 
if(ReadStick.ie Y)[ 
Inc+=ReadStick.ie_Y<0?-1: 
Speed=Inc/10; 


} 
} 
while(FindTask("TFunc^)); 
SetGPRequest(1,0PD SETCTYPE, 1, &Data) ; 
CloseW(); 
] 


VOID MSpeed() 

( 
BOOL kollision=FALSE; 
SHORT y=MAXH; 
UWORD elxdat=custom.clxdat; 


getad(); 
while(!Quit)[ 
Y+=Speed; 
if(RasInfo.RyOffset!=y)[ 
АҒ(у>МАХН) y=0; 
if(y«0) y=MAXH; 
RasInfo.RyOffsetzy; 
WaitTOF(); 
SerollVPort(&VPort); 
elxdat=custom.clxdat; 
if((kollision==FALSE)&&( (clxdat&4)==4)){ 
kollision=TRUE; 
Speed=Inc=0; 
SetRGBA(&VPort,0,15, 0, 0); 
Delay(5); 
SetRGBA(&VPort,0,15,15,15); 
] 


else kollision=FALSE; 


Listing 1. Das Beispielprogramm scrollt 
eine 2000 x 200 Pixel große BitMap 
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Kn OW-HOW 


Alternative zu Screens: die View-Struktur 


Intuition ausgebremst 


ten Speicher wieder frei: 
FreeColorMap(&CMap) ; 


Von Arno Gólzer 


Intuition ist leistungsfáhig 
und bedienerfreundlich, aber leider 


Der Parameter ist die Adres- 


zur Gestaltung des Bild- 

schirms zur Verfügung, die 
fast keine Wünsche offenlas- 
sen. Diese Vielseitigkeit fordert 
aber auch einen immensen 
Verwaltungsaufwand. Einen 
Aufwand, der bei der Program- 
mierung von Spielen nur selten 
gefragt ist. 

Wir steigen bei der Realisie- 
rung unseres Ziels - eines ein- 
fachen Grafikbildschirms - tie- 
fer ins Betriebssystem hinab 
und suchen die unterste Stufe 
des Displays. Eine kleine, un- 
scheinbare Struktur ist verant- 
wortlich für alles, was sich vor 
unseren Augen auf dem Moni- 
tor abspielt: die View-Struktur 
(Listing 1). 

Welche Bedeutung sie hat, 
wird bei der Besprechung der 
einzelnen Komponenten dieser 
wichtigen Struktur klarer: 
struct ViewPort *ViewPort 

verweist auf den ersten View- 
Port. Dieser ist ebenfalls eine 
Datenstruktur des Displays. In 
einem Task kónnen mehrere 
ViewPorts initialisiert "werden, 
aber nur einen View, der über 
sie wacht und ihre Fáhigkeiten 
in seiner Struktur festlegt. Wir 
werden ViewPorts gleich einge- 
hend beleuchten. Soviel sei 
vorweggenommen: Alle View- 
Ports eines Views sind mit dem 
ersten Element ihrer Struktur 
verkettet. Der letzte ViewPort 
enthált als Adresse des Folge- 
ViewPorts den Wert NULL. 
struct cprlist *LOFCprList 

die Adresse derLongFrame- 
Copper-Liste. Der Copper ist ei- 
ner der Coprozessoren des 
6800er-Chips. Er überwacht 
den Elektronenstrahl, der das 
Bild auf den Monitor zeichnet 
und belegt in Abhängigkeit von 
dessen Position die Register 
der Customchips mit Bild- 
schirmwerten. An welcher Posi- 
tion er diese Werte in die ver- 
schiedenen Register schreibt, 
wird in sogenannten Instruk- 
tionslisten festgelegt. LOFCpr- 
List ist die Adresse der Liste für 
ein Display ohne Zeilensprung- 
verfahren. 
struct cprlist «SHFCprList 

diese Copper-Instruktionsli- 
ste ist für den Auflösungs-Mo- 


| ntuition stellt uns Routinen 
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speicherintensiv und langsam. 
Hierbei hilft nur ein 
handgestricktes Display. 


dus Interlace notwendig. Bei 
diesem Modus wird eine beson- 
dere Technik, das .Zeilen- 
sprungverfahren, angewendet. 
Dabei teilt sich das darzustel- 
lende Bild in zwei Halbbilder, 
LongFrame und ShortFrame 
genannt, wobei SHFCprList die 
Adresse der Copper-Liste für 
ShortFrame ist. 


SHORT DyOffset,DxOffset 
bestimmen die X/Y - Position 

der linken oberen Ecke des 

Views auf dem Bildschirm. 


UWORD Modes 

die Darstellungsmodi ; des 
Amiga. Sie kennen sie aus der 

NewScreen-Strukturkompo- 
nente ViewModes. Im Headerfi- 
le graphics/view.h sind, neben 
der View-Struktur selbst, fol- 
gende Modi definiert: 
#define РЕВА 0x40L 
#define DUALPF 0x400L 
#define HIRES 0x8000L 
#define LACE 4L 
#define HAM 0x800L 
#define SPRITES 0x4000L 
#define VP_HIDE 0x2000L 
# define GENLOCK AUDIO 

0x100L 
# define GENLOCK VIDEO 

2L 
# define EXTRA HALFBRITE 

0x80L 

Sie werden bei der Bespre- 
chung der Strukturen in diesem 
Artikel immer wieder Parallelen 
zu Intuition-Elementen feststel- 
len, da diese auf den View- 
Strukturen basieren. Bei der Er- 
stellung eines eigenen Displays 
werden wir vom Betriebssystem 
mit mehreren Funktionen un- 
terstützt. So belegt z.B. Init- 


View(&View) die View-Struktur, 


auf die der als Parameter gelie- 
ferte Pointer verweist, mit den 
Standardwerten. Wir müssen 
spáter lediglich die Adresse des 
ersten ViewPorts und den View- 
Modus ergänzen. 


Der Displaymodus richtet 
sich nach den Anforderungen 
des Programmierers. Dieser 
muß dabei bedenken, daß ein 
dem View zugehörender View- 
Port nur die hier vereinbarten 
Auflösungsmodi verwenden 
kann. Hat man HIRES INTER 
LACE angegeben, so können 
die ViewPorts alle Bildschirm- 
auflösungen darstellen. Leider 
macht sich bei dieser Kombina- 
tion das lästige Interlace-Flim- 
mern bemerkbar - auch bei 
Viewports, die nicht in diesem 
Modus arbeiten (siehe Beispiel- 
programm Resolutions.c - Li- 
sting 5). Zur Komplettierung un- 
seres Views fehlt somit nur 
noch die Adresse der ersten 
ViewPort-Struktur. Bei dieser 
Struktur (Listing 2), welche 
ebenfalls in graphics/view.h 
vereinbart ist, läßt sich die enge 
Verwandtschaft mit dem Intui- 
tion-Screen nicht verleugnen. 
Hier die Bedeutung der einzel- 
nen Variablen: 
struct ViewPort «Next 

wie weiter oben erwähnt, 
sind alle ViewPorts eines Views 
miteinander verkettet. Der An- 
fang der Kette ist im ersten Ele- 
ment der View-Struktur ver- 
merkt. 


struct ColorMap *ColorMap 

jeder ViewPort verfügt über 
eine eigene ColorMap-Struktur, 
die unter anderem die Farben 
für den ViewPort enthált. Das 
bedeutet, daß Sie für jeden 
ViewPort eine komplette Far- 
benpalette benutzen können. 
Die Funktion GetColorMap legt 
uns die Struktur an: 


ViewPort.ColorMap= 
GetColorMap(n); 


Als Parameter erwartet die 
Struktur die Anzahl der Farben. 
Diese richtet sich nach dem ge- 
wáhlten ViewModus und der 
Anzahl der benutzten Bitpla- 
nes. Vor Ende des Programms 
gibt FreeColorMap() den beleg- 


se der mit GetColorMap() ange- 
legten ColorMap-Struktur. Es 
folgen die vier ViewPort- 
Copperlisten: 


struct CopList «Dsplns 
Instrüktionsliste für das Dis- 
play des ViewPorts. 
struct CopList «Sprins 
die Copperliste für die Dar- 
stellung von Sprites. 
struct CopList *Clrins 
dies ist die Color-Copperliste. 
struct UCopList *UCopIns 
dieses Feld kann auf eine 
vom Programmierer angelegte 
Copperliste verweisen. 


SHORT DWidth,DHeight 

hier werden die Ausmaße 
des ViewPorts in Pixel festge- 
legt. 


SHORT DxOffset,DyOffset 

die Position der linken obe- 
ren Ecke des  ViewPort- 
Rechtecks, als Offset zum ge- 
samten Display. Beachten Sie 
bitte, daß sich ViewPorts nicht 
überlappen dürfen. Mindestens 
eine Pixelreihe Abstand muB 
gehalten werden. Darüber hin- 
aus ist es nicht móglich, View- 
Ports nebeneinander darzustel- 
len. 


UWORD Modes 

die Darstellungsart des View- 
Ports. Es muB sich um einen 
der im Feld Modes der View- 
Struktur vereinbarten Modi 
handeln. 


UBYTE SpritePriorities 

Prioritäten der Sprites. Aller- 
dings ist die Spritepriorität 
hardwaremäßig festgelegt und 
nicht veränderbar. 


UBYTE reserved 
reserviert für System. 
struct Rasinfo *Rasinfo 
Verbindung des ViewPorts 
zur BitMap. Auch hier steht uns 
wieder eine Initialisierungsrou- 
tine zur Verfügung: 
InitVPort(&ViewPort) belegt 
die ViewPort-Struktur, auf die 
der Parameter verweist, mit 
Standardwerten. Nur vier Werte 
müssen wir ergänzen: die Brei- 
te und Hóhe des ViewPorts, der 
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Verweis auf die ColorMap und 
den Pointer auf die Rasinfo- 
Struktur. 

Als einzige Unbekannte 
bleibt uns die Raslnfo-Struktur 
(Listing 3). Sie kann, wie so vie- 
le Strukturen des Amiga-Be- 
triebssystems, mittels des er- 
sten Elements verkettet wer- 
den. Dies ist allerdings nur in 
den Spezialmodi, wie z.B. 
DUALPF notwendig. Es folgt 
die Adresse der BitMap-Struk- 
tur des Displays. Zum Schluß 
erwartet Навіпіо noch die X/Y- 
Koordinate des Punktes im Ra- 
ster, welcher an der linken obe- 
ren Ecke des ViewPorts darge- 
stellt werden soll. Leider stellt 
uns das Betriebssystem keine 
Funktion zur Verfügung, wel- 
che die Rasinfo-Struktur initiali- 
siert, was in Anbetracht ihrer 
Kürze entschuldbar ist. Tat- 
sächlich fehlt nur die Adresse 
der BitMap-Struktur. Diese 
Struktur (Listing 4) enthält 
gundlegende Informationen 
über das Display. Die Belegung 
der Komponenten besorgt: 


InitBitMap(&BM,AP,W,H); 


Als ersten Parameter erwar- 
tet die Funktion einen Zeiger 
auf die zu _ initialisierende 
BitMap-Struktur. Parameter 
zwei enthält die Anzahl der ge- 
wünschten Planes, während 
die beiden letzten Parameter 
die Breite und die Höhe einer 
Plane beschreiben. Dem Pro- 
grammierer bleibt die Aufgabe, 
Speicherplatz für die Planes zu 
allokieren und deren Adressen 
bekanntzugeben: 


for (1=0;1<АР;1++)[ 
if(!(BM.Planes[i]= 
(PLANEPTR)AllocRaster 
(W,H))) Error(); 
BltClear(BM.Planes[i], 
RASSIZE(W,H),0); 

] 


Die Variablen entsprechen 
den Parametern des InitBit- 
Map(-Aufrufs. Innerhalb des 
Schleifenrumpfes reserviert Al- 
locRaster den notwendigen 
Speicherplatz für jede Bitebe- 
ne, der von BltClear sogleich 
gelöscht wird. RASSIZE() ist ein 
Makro, welches die Größe des 
zu löschenden Bereichs ermit- 
telt. Es versteht sich von selbst, 
daß der für die Planes notwen- 
dige Speicher - allerdings nicht 
der für die verwaltende Struktur 
- im Chip-Memory liegen muß. 
Dafür sorgt AllocRaster(). Blt- 
Clear) kann auch durch 
SetRast(&RPcol) ersetzt wer- 
den, wie auch aus dem Demo- 
programm Resolutions.c er- 
sichtlich ist. Parameter sind 
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hierbei die Adresse des Rast- 
Ports und die gewünschte Far- 
be, mit welcher der Rastport ge- 
füllt werden soll. In einer Intui- 
tion-Umgebung erhalten wir die 
Adresse eines RastPorts pro- 
blemlos. Aber wie gelingt dies 
bei einem eigenen Display? Sie 
vermuten richtig, wir erstellen 
den RastPort selbst - oder bes- 
ser wir lassen ihn erstellen: 


InitRastPort(&RP); 
ЕР.Ві+Мар=8ВМ; 


InitRastPort() übernimmt die- 
se Aufgabe, wenn wir ihr die 
Adresse einer RastPort-Struk- 
tur übergeben. Wir müssen 
dann nur noch bekanntgeben, 
wo die BitMap-Struktur zu fin- 
den ist. Somit haben wir alle 
Daten beschafft, es trennen 
uns noch genau drei Funktions- 
aufrufe vom ersten eigenen 
Display. MakeViewPort(&View, 
&ViewPort) generiert aus den 
Daten der Strukturen View und 
ViewPort eine Copperliste. Falls 
die Komponente ColorMap der 
ViewPort-Struktur NULL ent- 
hált, nutzt MakeViewPort() eine 
Default-Farbtabelle. Die Para- 
meter sind die Adressen auf die 
fertig initialisierten Strukturen 
View und ViewPort. MrgCop(& 
View) fügt («merge») alle Cop- 
perlisten des Views mit der als 
Parameter gegebenen Adresse 
zu einer einzigen Instruktionsli- 
ste zusammen. Nun steht der 
Darstellung des Displays nichts 
mehr im Wege - oder? Stop! 
Wir müssen die Adresse des 
aktuellen Views noch retten, so 
daß wir unser Programm auch 
wieder korrekt beenden kön- 
nen: 


struct View OldView; 
OldView-GfxBase-» 
ActiView; 


Ist die Adresse des alten 
Views nicht bekannt, gibt es 
kein Zurück zur Workbench 
bzw. zum CLI-Window. Der Auf- 
ruf der Funktion LoadView- 
(&View) macht endlich das Dis- 


play sichtbar. Durch den Aufruf - 


dieser Funktion kann das Dis- 
play auch wieder in den Vorder- 
gund gebracht werden, wenn 
durch die Tastenkombination 
«Linke Amiga n> der Work- 
benchscreen nach vorne ge- 
klappt wurde. Zum besseren 
Verstándnis sind alle bespro- 
chenen Prozeduren im Bei- 
spielprogramm  Resolutions.c 
anschaulich demonstriert. Das 
Programm, welches Ihre Einga- 
ben vom Joystick in Port 2 er- 
wartet, erstellt ein Display im 
LoRes-Modus. Durch Betáti- 
gung des Sticks in die vier Rich- 
tungen schalten Sie auf einen 


anderen Auflósungsmodus um. 
Programmende erfolgt nach 
der Betätigung des Feuer- 
knopfs. 

OpenW() ermittelt die Basis- 
adresse der Graphics-Library, 
öffnet das GamePort-Device 
und erledigt die Initialisierung 
der Strukturen für das Display. 

InitStick() macht ihrem Na- 
men alle Ehre, sie initialisiert 
über SetGPRequest() Game- 
Port 2 (der rechte Port) für den 
Joystick. 

Die Funktion DrawVP() zeich- 
net einige Ellipsen auf den neu 
initialisierten RastPort und 
macht die Zeichnung mittels 
LoadView() sichbar. Danach 
warten wir in main() mittels 
WaitlO() auf die Betätigung des 
Sticks. Entsprechend der ge- 
wählten Richtung schalten wir 
den Modus um und berechnen 
die Copperlisten neu. Nach Be- 


tätigung des Feuerbuttons дім” 


CloseW() den reservierten 
Speicher wieder frei. 

Wenn der alte View wieder 
eingeschaltet ist, wir warten zur 
Sicherheit mit WaitTOF() bis der 


struct View 

[ 
Struet ViewPort *ViewPort; 
struct eprlist *LOFCprList; 
struct cprlist *SHFCprList; 


SHORT DyOffset,DxOffset; 
UWORD Modes; 


Ja 


Listing 1. Die View-Struktur 


Elektronenstrahl die linke obere 
Ecke des Bildschirms erreicht 
hat, geben den für die Copper- 
listen notwendigen Speicher 
wieder ans System zurück. 
FreeVPortCopLists(&ViewPort) 
gibt die Listen des ViewPorts 
frei. Die Funktionen FreeCpr- 
List(View.LOFCprList) und 
FreeCprList(View.SHFOprList) 
verrichten diese Arbeit für die 
Listen der View-Struktur. Die 
hier geschilderten Funktionen 
Sind schnell in Programme, 
welche auf Intuition verzichten 
kónnen, übernommen und dem 
jeweiligen Spiel angepaßt. Be- 
lohnt werden Sie für den Pro- 
grammieraufwand mit einem 
rasanten Bildschirmaufbau und 
einem geringen Speicherbe- 
darf. Sicher sind Sie mit uns der 
Meinung, daB dies der gerin- 
gen Mühe wert war. pe 


Der Autor Arno Gölzer ist eiri Mann der ersten 
Stunde und schreibt schon einige Jahre für 
das AMIGA-Magazin und die AMIGA-Sonder- 
hefte. Sie können ihn erreichen über unsere 
Verlagsanschrift (Markt & Technik Verlag AG, 
Redaktion Sonderhefte, z. Hd. Herrn Gölzer, 
Hans-Pinsel-Straße 2, 8013 Haar b. München). 


stellt die unterste Ebene des Displays dar 


struct ViewPort 

( 
struct ViewPort XNext; 
struct ColorMap *ColorMap; 
struct CopList *DspIns; 
struct CopList *SprIns; 
struct CopList X*ClrIns; 
struct UCopList *UCopIns; 
SHORT DWidth,DHeight; 
SHORT DxOffset,DyOffset; 
UWORD Modes; 
UBYTE SpritePriorities; 
UBYTE reserved; 
struct RasInfo *RasInfo; 


Ji 


Listing 2. Der ViewPort ist 


eng mit dem Intuition-Screen verwandt 


struct RasInfo 

{ 
struct RasInfo *Next; 
struct BitMap *BitMap; 


SHORT RxOffset,RyOffset; 
J; 


Listing 3. Die Rasinfo-Struktur 
koppelt ViewPort und BitMap 
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if(!(GfxBase=(struct GfxBase X) 
OpenLibrary("graphics.library^,0))). CloseW(); 

if(!(GPort=CreatePort( ”GPort”,0))) C1oseW(); 

if(!(GPRequesteCreateStdIO(GPort))) CloseW(); 

4f(GPDev=(ULONG) 
OpenDevice("gameport.device",1,GPRequest,0)) CloseW(); 

O1dView=GfxBase->ActiView; 

InitView(&View); 

InitVPort(&VPort); 

InitRastPort(&RP); 

InitBitMap(&BMap, 1, WIDTH, HEIGHT) ; 

if (!(BMap.Planes[0]- (PLANEPTR) 
AllocRaster(WIDTH,HEIGHT))) Closeh(); 

View.ViewPort =&VPort; 

View.Modes ^ -HIRESILACE; 

VPort.DWidth =WIDTH; 

VPort.DHeight ^ -HEIGHT; 

VPort.RasInfo =&RasInfo; 

VPort.ColorMap ^ -GetColorMap(2); 

RasInfo.BitMap =&BMap; 

RasInfo.RxOffset=0; 

RasInfo.RyOffset=0; 

RasInfo.Next =NULL; 

RP.BitMap =8ВМар; 

SetRGB4(&VPort,0, 5, 5, 5); 

SetRGBA(&VPort,1,10,10,10); 

MakeVPort (&View,&VPort); 

MrgCop(&View); 


struct BitMap 

( 
UWORD BytesPerRow; /% Bytes pro BitMap-Zeile (Breite/8) %/ 
UWORD Rows; /* Anzahl der Zeilen (Höhe) %/ 
UBYTE Flags; /* ??? ungenutzt */ 
UBYTE Depth; /* Anzahl der BitPlanen (BitEbenen) */ 
UWORD pad; /% Platzhalter - PLANEPTR beginnen auf LONGWORD */ 
PLANEPTR Planes[8]; /* die Adressen der BitEbenen 

im Speicher */ 


Listing 4. Die BitMap 
enthált elementare Daten über das Display 


ya 
Aztec C 3.4a 

cc Resolutions.c +L 
1n Resolutions.o -1¢32 


Gólzy's Resolutions.c - die Bildschirmausflósungen des Amiga 


X include <exec/memory.h> 
#include <ехес/%урев.һ> 
#include < graphics/gfxbase.h» 
#include <graphics/view.h> 
#include <devices/inputevent.h> 
#include <devices/gameport.h> 
#include <functions.h> 


) 


VOID Print(mnr) 


SHORT mnr; 

#define WIDTH 320 

#define HEIGHT 256 

ULONG GPDev; 

UWORD Mode[4]={ 
0,LACE,HIRES,HIRESI LACE 


SHORT len=strlen(MText(mnr]) ; 


SetAPen(&RP, 1) ; 
SetDrMd(&RP, JAM2) ; 

Move(&RP  WIDTH/2-1en*4, 50) ; 
Text(&RP,MText[mnr],1en); 


1; 

STRPTR MText[4]={ 
(STRPTR)" LoRes - Modus ”, 
(STRPTR)” LowLace - Modus ”, 
(STRPTR)" HiRes - Modus ^, 
(STRPTR)" Hilace - Modus " 


] 


VOID SetGPRequest(doit,c,1,d) 
BOOL doit; 
UWORD e; 
ULONG 1; 
APTR dj 


Ji d 2 
struct GamePortTrigger GPTrigger=[ 
GPTF_UPKEYSI GPTF_DOWNKEYS,0,1, 1 


GPRequest->io_Command =c; 
GPRequest->io_Length =1; 
GPRequest->io_Data =й; 
if(doit) DoIO(GPRequest); 


struct GfxBase *GfxBase; 
struct View *01dView, View; 
struct MsgPort *GPort; 
struct I0StdReq *GPRequest; 
struct InputEvent ReadStick; 
struct ViewPort VPort; 
struct RasInfo RasInfo; 
struct BitMap BMap; 

struct RastPort RP; 


) 


VOID InitStick() 
( 

UBYTE Data=GPCT_RELJOYSTICK; 

ULONG 1g-sizeof(struct GamePortTrigger), 
VOID CloseW() lissizeof(struct InputEvent); 
SetGPRequest(1,GPD_SETCTYPE,1,&Data) ; 
SetGPRequest(1,GPD. SETTRIOGER, 1g, &GPTrigger); 
SetGPRequest(0,GPD_READEVENT, 11, &ReadStick); 


if(OlaView){ 
LoadView(OldView); 
WeitTOF(); 


) 


VOID DrawVP() 


( 


REGISTER SHORT i; 


) 


FreeVPortCopLists(&VPort) ; 

FreeCprList(View.LOFCprList) ; 

FreeCprList(View.SHFCprList) ; 

if(VPort.ColorMap)  FreeColorMap(VPort.ColorMap) ; 
if(BMap.Planes(0]) FreeRaster(BMap.Planes(0],WIDTH, HEIGHT); 
if(GPDev) CloseDevice(GPRequest) ; 

if(GPRequest) DeleteStdIO(GPRequest); 

if(GPort) DeletePort(GPort) ; 

if(GfxBase) CloseLibrary(GfxBase); 

exit(0); 


SetRast(&RP,1); 

Print(0); 

SetAPen(&RP,0); 

for(1=32;1<WIDTH-1;1+=32) 
DrawEllipse(8&RP,i-1,140,32,1/10); 

j LoadView(&View) ; 

VOID Орепи() 


[ 


Listing 5. Resolutions.c demonstriert, 
wie man ein Display selbst erstellen kann 


REGISTER SHORT i; 
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VOID main () 
f 
t 
UBYTE Data=GPCT_NOCONTROLLER 
SHORT nr: 
OpenW(); 
InitStick(); 
DrawVP(); 
while(1)[ 
SendIO(GPRequest) ; 
WaitlO(GPRequest); 
if(ReadStick.ie Codes-IECODE LBUTTON) break 
else if(ReadStick.ie X) nr=(ReadStick.ie_X>0)20:1; 


An der 


Ver 


else if(ReadStick.ie Y) nr=(ReadStick.ie_Y>0)?2:3; 


VPort.Modes=Mode[nr]; 
MakeVPort(&View,&VPort); 
MrgCop(&View); 
LoadView(&View) ; 
Print(nr) ; 


) 


SetGPRequest(1,GPD_SETCTYPE,1,&Data) ; 


CloseW(); 


| 
J 


Listing 5. (Schluß) 


Von Arno Gölzer 


ereits beim Aufbau ei- 
nes einfachen Grafik- 
Displays (Sie finden in 
diesem Heft auf Seite 77 einen 
Artikel, der sich damit befaßt.) 
werden Sie, wenn auch eher 
am Rande, mit dem Copper 
konfrontiert. Es geht dabei um 
die Erstellung der Copper- 
Programme, den sogenannten 
Copper-Listen, durch die Be- 
triebssystem-Funktionen Make- 
VPort() und MrgCop(). 
MakeVPort() ist für die View- 
Port-(Zwischen-)Listen zustän- 
dig. MrgCop() fügt diese zu der 
Gesamt-(Hardware-)Instruk- 
tionsliste des Displays zusam- 
men. Je nach Auflösungsmo- 
dus generieren die Funktionen 
eine oder - im Interlace-Modus 
- zwei Listen. Mit dem Aufruf 
der LoadView()-Funktion wer- 
den die Adressen dieser Listen 
in die Custom-Register »copilc« 
und »cop2lc« übertragen und 


Die enormen Fáhigkeiten auf 
dem Gebiet der Grafik 
verdankt der Amiga nicht 
zuletzt seinen Coprozessoren. 
Einer dieser Coprozessoren 
ist entscheidend am Bildaufbau 
beteiligt: der Copper. 


der Copper beginnt mit deren 
Ausführung. 

Arbeiten Sie mit einem Intui- 
tion-Screen, so brauchen Sie 
sich um die Freigabe des für die 
Copperlisten notwendigen 
Speichers vor Programmende 
nicht zu kümmern. Beim 
SchlieBen des Screens gibt In- 
tuition alle zugehórigen Cop- 
perlisten, auch die User-Cop- 
perlisten, wieder frei. 

Haben Sie jedoch Ihr Display 
unabhángig von Intuition »ge- 
zimmert«, so sollten Sie als dis- 
ziplinierter Programmierer die 
für die Listen reservierten Spei- 
cherplätze mittels der Funktio- 
nen FreeCopList() und Free- 
CprList() wieder freigeben. Die 
zuletzt genannte Funktion 
übernimmt die Freigabe der 
Hardware-Copperliste. Beide 
Funktionen erwarten die ent- 
sprechenden Strukturpointer. 
Ein Beispiel: 


FreeCprList(View.LOF 
CprList); /ж struct 


Coppercabana 


eprlist x/ 
FreeCopList(ViewPort. 
CopList); /x struct 
CopList x/ 


FreeVPortCopLists(&ViewPort) 
kann die Funktion FreeCop- 
List() ersetzen, sie gibt alle Cop- 
perlisten des genannten View- 
Ports frei, auch die vom User 
selbst installierten. 

Móchte man nur die User- 
Copperliste entfernen, hilft der 
Aufruf der FreeVPortCopLists()- 
Funktion, mit nachfolgender 
Neuberechnung des Displays - 
ohne User-CopperListe. Im 
Grafikdisplay geschieht das wie 
gewohnt mit den oben erwähn- 
ten Funktionen. Bei der Arbeit 
mit Intuition genügt der Aufruf 
der Funktion RemakeDisplay(). 

Die enge Verwandtschaft des 
Coppers mit dem Elektronen- 
strahl, der das Bild auf dem Mo- 
nitor aufbaut, läßt sich nach der 
Besprechung der folgenden 
Copper-Funktionen nicht mehr 
leugnen: WaitTOF() wartet, bis 
der Elektronenstrahl mit dem 
Neuaufbau des Bildes beginnt. 
Diese Funktion setzt man vor- 
nehmlich dort ein, wo der Bild- 
schirmaufbau einer stándigen 
Veránderung unterliegt. Sie 
vermeiden so das unschóne 
Flackern, welches z.B: wäh- 
rend des Scrollings oder bei ei- 
ner bewegten Grafik entstehen 
kann. 

Die Funktion WaitBOVP(& 
ViewPort) stellt in gewisser Hin- 
Sicht das Gegenstück zu Wait- 
TOF() dar. Sie hält das auszu- 
führende Programm so lange 
an, bis der Elektronenstrahl die 
unterste Zeile des ViewPorts er- 
reicht hat, dessen Adresse als 
Parameter übergeben wurde. 

Das letzte Beispiel, VBeam- 
Post, ermittelt die aktuelle Y- 
Position des Elektronenstrahls: 
ULONG YPos; 
YPos=VBeamPos(); 

Bis zur Rückgabe und vor al- 
lem bis zur Auswertung des 
Rückgabewertes, stimmt dieser 
natürlich in aller Regel nicht 
mehr mit der tatsächlichen 
Strahlposition überein. Den- 
noch findet die Funktion, gera- 
de bei der Spieleprogrammie- 
rung, einen sinnvollen Einsatz. 
Ihr Ergebnis kann als Zufalls- 
zahl oder zumindest als Ver- 
knüpfungs- oder Startwert für 
die in den Compiler-Libraries 
enthaltenen Zufallszahlgenera- 
toren dienen. 

Sie sehen, die Arbeit des 
Coppers ist tatsächlich sehr 
eng an den Elektronenstrahl 
oder besser an dessen Position 
gebunden. Seine Aufgabe be- 
steht darin, auf eine bestimmte 
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Rasterposition zu warten und 
beim Erreichen dieser Position 
den Inhalt eines Customchip- 
Registers zu ändern. 

Die Register befinden sich ab 
der Adresse OxDFFOOO іт 
Speicher. Jedoch sollten Sie 
nicht direkt, sondern über die 
im Headerfile »hardware/cu- 
stom.h« definierte Custom- 
Struktur auf die Register zu- 
greifen. Listing 1 stellt die 
Struktur vor und erläutert grob 
den Inhalt der einzelnen Kom- 
ponenten. 

Listing 1 zeigt, daß Copper 
nicht auf alle Register Zugriff 
hat. Auf die Register bis ein- 
schließlich »strlong« hat er kei- 
nen Einfluß und auf die folgen- 
den, bis »dsksync«, nur dann, 
wenn Bit 0 des Copper-Gontrol- 
registers »copcon« gesetzt war. 

Die Inhalte der übrigen Regi- 
ster können jederzeit über den 
Copper manipuliert werden. 
Zum Aufbau der hierzu notwen- 
digen Copperliste stellt das Be- 
triebssystem dem Programmie- 
rer drei Funktionen zur Verfü- 
gung: 

CWait(&UCList,y,x); 
CMove(&UCList,r,w); 
CBump(&UCList); 


Mit diesem nicht gerade ge- 
waltigen Arsenal von Befehlen 
lassen sich, in Verbindung mit 
den Hardware-Registern, die 
tollsten Effekte erzielen, z.B. 
vielfarbige Schriften. Aber auch 
die in vertikaler Richtung ver- 
schiebbaren Intuition-Screens 
und die VSprites erzeugen Sie 
‚auf diese Weise. 

Eigentlich existiert neben 
Wait und Move noch der Skip- 
Befehl, der dafür sorgt, daß der 
nachfolgende Befehl der Cop- 
perliste übersprungen wird, 
falls sich der Rasterstrahl be- 
reits unterhalb der angegebe- 
nen Position befindet. Dieser 
bleibt allerdings Assembler- 
Programmierern vorbehalten. 
In den Hochsprachen müssen 
wir auf Skip verzichten und uns 
mit den oben genannten Funk- 
tionen begnügen. Mit ihrer Hilfe 
bauen wir unsere Copperlisten 
auf. 

CWait() implementiert in der 
Copperliste der  UCopList- 
Struktur, auf die der erste Para- 
meter verweist, den Befehl 
Wait. Dieser Befehl veranlaßt 
den Copper dazu, zu warten, 
bis der Elektronenstrahl die 
über die Parameter y und x an- 
gegebene Position auf dem 
Bildschirm erreicht. Beachten 
Sie bitte, daß die Funktion da- 
bei den y-Wert vor dem x-Wert 
erwartet! Die Nullinie der y- 
Position ist die oberste Zeile 
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des ViewPorts, in dem die Cop- 
perliste eingebunden wird. Die 
erste x-Position (Null) befindet 
sich links, ca. 55 bis 65 Positio- 
nen (je nach Einstellung des X- 
Offsets) auBerhalb des eigentli- 
chen Displays (siehe auch Li- 
sting 2 und 3). Der Start des 
Displays liegt also etwa bei Po- 
sition 60, das Ende bei etwa 
220. Daraus errechnet eine 
Wait-Auflösung von 4 Pixel im 
Hires-Modus fir das Display 
(640/(220-60). Nach jedem 
Copper-Kommando muß der 
Befehlszeiger der Liste mittels 
der CBump()-Funktion erhöht 
werden. Glücklicherweise sind 
jedoch im Headerfile »gra- 
phics/gfxmacros.h« für den ver- 
geBlichen Programmierer Ma- 
kros definiert, die die Inkremen- 
tierung übernehmen: CWAIT() 
und CMOVE(). Beide werden 
mit den gleichen Parametern 
wie die entsprechenden Funk- 
tionen aufgerufen. Leider hat 
man auf das Vertauschen 
der Positionsparameter des 
CWAIT(-Makros verzichtet. 
Nachdem der Elektronenstrahl 
die in Wait vorgeschriebene Po- 
Sition erreicht hat, belegt Move 
das angegebene Register mit 
einem beliebigen Wert. 
CMOVE() baut die notwendi- 
gen Befehle in unsere Copperli- 
ste ein. Der zweite Parameter 
des Makros ist das gewünschte 
Register, Parameter 3 stellt den 
Wert dar, der in dieses Register 
eingetragen werden soll. Die 
kleinste Auflósung in vertikaler 
Richtung betrágt ein Pixel. In 


Vom Strahl 
ausgebremst 


horizontaler Richtung macht 
sich jedoch die rasante Ge- 
schwindigkeit des Elektronen- 
strahls und die Ausführungszeit 
der Befehle Wait und Move be- 
merkbar: 


CWAIT(&UCList,0,60); 
CMOVE(&UCList,custom. 
color[0],0xF00); 
CMOVE(&UCList, custom. 
color[0],OxFFF); 


Diese Zeilen sollten eigent- 
lich ein Programm erzeugen, 
welches die linke obere Ecke 
des Displays kurz rot und da- 
nach gleich wieder weiß färben 
sollte. Wegen der oben genann- 
ten Gründe erscheint jedoch ei- 
ne, im Hires-Modus ca. 16 Pixel 
lange rote Linie. Sollten Sie ver- 
suchen, Copper und Elektro- 
nenstrahl mit der folgenden Se- 
quenz zu überlisten... 


CWAIT(&UCList,0,60); 
CMOVE(&UCList,custom. 


color[0],OxF00); 
CWAIT(&UCList,0,62); 
CMOVE(&UCList,custom. 

color[0],0xFFF) ; 


...und zu einer höheren Auflö- 
sung zu zwingen, ernten Sie 
vom Copper nur Hohngelächter 
und von Ihrem Display eine 
noch längere Linie, denn auch 
Wait hat natürlich, wie oben er- 
wähnt, seine Ausführungszeit. 

Die mit Hilfe der beiden Ma- 
kros aufgebaute Copperliste 
wird bei jedem Strahldurchlauf 
abgearbeitet. Damit dies kor- 
rekt geschehen kann, darf sie 
eine bestimmte Länge nicht 
überschreiten. Stellen Sie sich 
vor, der Elektronenstrahl er- 
reicht die rechte untere Ecke 
des Displays, also die Endposi- 
tion, während der Copper noch 
mit seiner Instruktionsliste zu 
kämpfen hat. 

Das Ende einer Copperliste 
kennzeichnet ein Befehl, den 
der Copper nicht ausführen 
kann: CWAIT(&UCList,10000, 
255). Demnach wartet er, bis 
ihn der náchste Start des Elek- 
tronenstrahls in der linken obe- 
ren Display-Ecke auffordert, 
seine Instruktionsliste erneut 
zu bearbeiten. 

Für diese »SchluBmarkie- 
rung« existiert ein weiteres Ma- 
kro, welches nur noch die 
Adresse der UCopList-Struktur 
verlangt: 


CEND(&UCList); 
Jetzt steht dem Start unserer 
eigenen  Copperliste nichts 


mehr im Wege. Nachdem wir 
die Adresse unserer UCopList- 
Struktur im gewünschten View- 
Port bekanntgegeben haben, 
fehlt nur noch die Einbindung 
der Liste mittels MakeVPort() 
und MrgCop() bzw. unter Intui- 
tion, RemakeDisplay(). Danach 
arbeitet der Copper immer wie- 
der das gleiche Programm ab - 
50mal in einer Sekunde. 

Der Aufbau einer veránder- 
baren Copperliste - z.B. kónn- 
ten Sieimmer an der Mausposi- 
tion die Hindergrundfarbe für 
mehrere Zeilen verändern - ist 
leider nicht ohne weiteres mög- 
lich. Die Copperliste muß vor je- 
dem Neuaufbau »gesäubert« 
werden. Hierzu dient die Funk- 
tion UCopListInit(&UCList,n) 
oder kürzer, als Makro: 


CINIT(&UCList,n); 


Die UCopList-Struktur ent- 
hält die Adresse der vom User 
definierten Copperliste (verglei- 
che Headerfile graphics/cop- 
per.h). Ist diese Adresse gleich 
NULL, legt die Funktion einen 
Buffer an, der »n« Einträge auf- 
nehmen kann und liefert einen 
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Zeiger darauf. Achtung: Diese 
Funktion legt allen Behauptun- 
gen in der gängigen Literatur 
zum Trotz kein UCopList-Struk- 
‚tur an! Der Speicher für diese 
Struktur muß, wie im Beispiel- 
programm gezeigt, mit Alloc- 
Mem() angefordert werden. 
Gibt man aber als Parameter 
des CINIT()-Makros die Adres- 
se einer UCopList-Struktur an, 
die bereits die Adresse einer 
User-Copperliste enthält, so 
bereitet das Makro die Struktur 
auf die Aufnahme einer neuen 
Copperliste vor. Nochmals Ach- 
tung: Es genügt nicht, wenn Sie 
die Struktur einfach löschen! 
Sie könnten dann zwar auch ei- 
ne neue Copperliste aufbauen 
lassen, aber Sie verlieren den 
Verweis auf die alte Liste - so- 
mit können Sie den dafür reser- 
vierten Speicher nicht mehr 
freigeben! 

Listing 2 zeigt den wichtig- 
sten Teil eines Programms, mit 
der Lösung für eine veränder- 
bare (oder besser: neu aufbau- 
bare) User-Copperliste (eine 
fertige Lösung bietet das Pro- 
gramm »HotBottom« - siehe 
den Artikel »Cola, Fanta, Sprite« 
auf Seite 53). In MakeCList() 
reinitialisiert der Aufruf des Ma- 
kros CINIT() bei jedem Aufruf 
der Funktion die UCopList- 
Struktur, so daß sofort eine 
neue Copperliste - speziell für 


struct Custom[ 


die neue Y-Position des Maus- 
zeigers - aufgebaut werden 
kann. Die Liste veranlaBt den 
Copper, in einem Bereich von 
10 Pixel um die Pointerposition 
den Wert des Farbregisters 0 zu 
ándern. Wir erreichen das Re- 
gister sehr einfach über die Cu- 
stom-Struktur: 


custom.color[0] 


Auch in unserem Demo-Li- 
sting (Listing 3) arbeiten wir mit 
Farben. CLIColor demonstriert 
die Handhabung des Coppers 
an einem einfachen Beispiel. 
Das Programm óffnet ein klei- 
nes Fenster in der Titelleiste 
des Workbenchscreens und 


Vielfalt mit 
zwei Planes 


stellt den Hintergund dieses 
(immer noch nur 2 Bit-Planes 
groBen) Screens in 16 verschie- 
denen Farbtónen dar - bis das 
Window geschlossen wird. 
Rufen Sie das Programm aus 
dem CLI mit »RUN« auf, so kön- 
nen Sie problemlos weiterarbei- 
ten. Die Hauptfunktion main() 
ruft gleich zu Beginn die Funk- 
tion OpenW() auf. Diese óffnet 
die benótigten Libraries und 
das Window. Weiterhin ver- 
schafft sie uns den Speicher für 
die UCopList-Struktur für den 
Strukturpointer UCList. 


/* Copper hat keinen Zugriff auf die folgenden Register: */ 


UWORD bltddat; 

UWORD dmaconr; 

UWORD vposr; 
Position lesen */ 


/* Blitter Ausgabedaten %/ 
/* DMA-Kontrollregister lesen */ 
/* Höherwert. Bit der vertikalen E.Strahl- 


UWORD vhposr; /% Vert. und horiz. E.Strahl-Position lesen */ 


Warum vereinbaren wir nicht 
anstelle des Zeigers gleich eine 
komplette UCopList-Struktur? 
Bedenken Sie bitte, daß die 
Funktion FreeVPortCopLists() 
nicht nur den Speicher für die 
Copperliste, sondern auch den 
für die Struktur freigibt. Nach 
Programmende werden aber 
neben dem Speicher für den 
Programmcode auch die Spei- 
cheradressen aller Variablen 
freigegeben - darunter auch 
unsere UCopList-Struktur. Das 
Resultat ist ein besonders hä- 
misch blinkender 0009er Guru! 

Noch eine Frage: Müßte die 
Struktur nicht im Chip-Memory 
liegen, da doch der Copper nur 
Daten, die in den unteren 512 
KByte abgelegt sind, verarbei- 
ten kann? Nein!!! Den Copper 
interessiert nur seine Instruk- 
tionsliste und nicht die Struktur, 


die diese Liste verwaltet. Die Li+ 


ste liegt selbstverstándlich im 
Chip-Memory. 

Die Funktion MakeCList() 
baut im Demo eine Copperliste 
von 33 Instruktionen zusam- 
men. CWAIT( und CMOVE() 
wechseln sich ständig ab. 
CMOVE\() ändert dabei den In- 
halt den Farbregisters 0, in Ab- 
hángigkeit der Schleifenvaria- 
ble. CEND() schließt die Liste 
ab. Nach der Belegung der 
ViewPort-Variable ^ UCoplns, 
wird sie mit der Intuition-Funk- 


ist: WA 


UWORD strlong; /* Kennzeichnung für lange horizontale Zeile #/ 
/* Copper hat Zugriff auf die folgenden Register, wenn copcon gesetzt 


UWORD bltcon0; /* Blitter Kontroll-Register 0 */ 
UWORD bltconi; /* Blitter Kontroll-Register 0 */ 
UWORD bltafwm; /* Maske für erstes Datenwort */ 
UWORD bltalwm; /* Maske für leztes Datenwort %/ 


tion RemakeDisplay() gestartet. 
Danach wartet CLICol nur noch 
auf die Betätigung des Close- | 
Gadgets. CloseW() sorgt für die 
Freigabe aller Ressourcen. Sie 
sehen, welche Effekte Sie, 
dank des Coppers, mit einem 
kleinen Programm von nicht 
einmal einer Seite erreichen 
kónnen. Dabei haben wir uns 
nur um Farbregister 0 geküm- 
mert und alle anderen Register 
außer acht gelassen - Listing 1 
láBt ahnen, welche Móglichkei- 
ten offenstehen. 

Vielleicht versuchen Sie sich 
selbst einmal mit der Copper- 
Programmierung? Bedenken 
Sie, was Sie alleine mit der Ma- 
nipulation des Farbregisters der 
Schriftfarbe erreichen kónnen! 
Also los - sofort testen ist ange- 
sagt. Sie müssen nur in MakeC- 
List die Nullen in GetRGB4() 
und in CMOVE() gegen eine 
Eins tauschen! Oder versuchen 
Sie sich doch gleich mit der ver- 
änderbaren Copperliste aus Li- 
Sting 2. Ganz gleich wie Sie 
Sich entscheiden, wir sind si- 
cher: Sie werden dabei eine 
Menge Spaß haben! so 
Arno Gólzer ist ein Mann der ersten Stunde 
und schreibt schon seit über zwei Jahren für 
das AMIGA-Magazin und die AMIGA-Sonder- 
hefte. Sie können ihn über unsere Verlags- 
adresse erreichen (Markt & Technik Verlag AG, 
Redaktion Sonderhefte, z. Hd. Herrn Arno Göl- 


zer, Hans-Pinsel-Straße 2, 8013 Haar bei Mün- 
chen). 


UWORD dskdatr; 


/* 


Disk-Daten lesen */ 


UWORD joyOdat; /* Daten f Maus od Joystick an Port O (links) */ 


UWORD јоу1да+; 
(rechts) */ 
UWORD elxdat; 
UWORD adkconr; 
UWORD potOdat; 
UWORD potidat; 
UWORD potinp; 
UWORD serdatr; 
UWORD dskbytr; 
UWORD intenar; 
UWORD intreqr; 
APTR dskpt; 
UWORD dsklen; 
UWORD dskdat; 
UWORD refptr; 
UWORD vposw; 
Schreiben */ 
UWORD vhposw; 
schreiben */ 
UWORD сорсоп; 
UWORD serdat; 
UWORD serper; 
UWORD potgo; 
Zugriff */ 
UWORD joytest; 
UWORD strequ; 
UWORD strvbl; 
UWORD. strhor; 


/* 


/* 
/* 
/* 


Daten für Maus oder Joystick an Port 1 


Kollisions-Datenregister lesen */ 
Audio- und Diskkontrolle lesen */ 
Potentionmeterstand Port 0 (links) lesen */ 


/* Potentionmeterstand Port 1 (rechts) lesen */ 


/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


Potentiometer-Pin Daten lesen %/ 

Serieller Port Daten und Status lesen */ 
Disk-Datenbyte lesen %/ 

Interrupt-Enable lesen */ 
Interrupt-Request lesen */ 

Adresse der Disk-Daten */ 

Lünge der Disk-Daten */ 

Disk-Daten schreiben %/ 

Memory Refresh Pointer */ 

Höherwert. Bit der vertikalen E.Strahl-Pos. 


/* Vertikale und horizontale E.Strahl-Position 


/* 


Copper Kontrollregister */ 


/* Serieller Port Daten und Stopbits schreiben */ 
/* Serieller Port Kontrollregister und Baudrate #/ 


/* 


/* 
/* für 
/* 
/* 


Potentiometer-Port Daten schreiben; Start bei 


Initialisiert joyOdat und Joyldat */ 
horiz. Syne. mit Vert.Blank und EquFrame %/ 
Strobe für horiz. Sync. mit Vert. Blank */ 
Strobe für horizontale Synehroisation */ 


АРТЕ bltept; /* Adresse der Blitter-Quelldaten C */ 
АРТЕ bltbpt; /* Adresse der Blitter-Quelldaten B %/ 
АРТЕ bltapt; /* Adresse der Blitter-Quelldaten A */ 
АРТЕ bltdpt; /* Adresse der Blitter-Zieldaten */ 
UWORD bltsize; /* Dimension des Blitter-Rechtecks;Start bei 
Zugriff */ 


UWORD pad2d[3]; /%- %/ 
UWORD bltemod; /* Blitter-Modulo für Quelldaten C */ 
UWORD bltbmod; /* Blitter-Modulo für Quelldaten B */ 
UWORD bltamod; /* Blitter-Modulo für Quelldaten A */ 
UWORD bltdmod; /* Blitter-Modulo für Zieldaten */ 
UWORD pad34[4]; /%-%/ 
UWORD bitedat; /* Blitter Quell-Datenregister C */ 
UWORD bltbdat; /* Blitter Quell-Datenregister В */ 
UWORD bltadat; /* Blitter Quell-Datenregister A */ 
UWORD pad3b[4]; /* - X/ 
UWORD dsksyne; /* Disk-Syncronisationscode */ 
/* Copper hat immer Zugriff auf die folgenden Register: */ 
ULONG copile; /* Adresse der Long-Frame Copperliste */ 
ULONG cop21e; /* Adresse der Short-Frame Copperliste */ 
UWORD copjmpi; /% bei Zugriff Start der Copperliste copile */ 
UWORD copjmp2; ^ /* bei Zugriff Start der Copperliste cop2le */ 
UWORD copins; /* Copper Befehlsregister */ 
UWORD diwstrt; /* linke obere Ecke des Displays */ 
UWORD diwstop; /% rechte untere Ecke des Displays %/ 
UWORD ddfstrt; /* Beginn Display-Daten */ 
UWORD ddfstop; /% Ende Display-Daten %/ 


UWORD dmacon; /* DMA-Kontrollregister schreiben */ 
UWORD elxcon; /* Kollisionskontrolle schreiben */ 
UWORD intena; /* Interrupt-Enable schreiben %/ 
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UWORD intreq; /* Interrupt-Request schreiben */ 
UWORD adkcon; /* Audio- und Diskkontrolle schreiben */ 
struct AudChannel[ 
UWORD *ac_ptr; /% Adresse der Audio-Daten */ 
UWORD ac_len; /* Länge der Daten ab Adresse ac ptr %/ 
UWORD ac. per; /* Periodendauer */ 
UWORD ac vol; /% Lautstärke */ 
UWORD ac.dat; /% DMA-Datenbuffer */ 
UWORD ac_pad[2];/* - */ 
] aud[4]; /* die vier Audio-Kanäle */ 
APTR bplpt(6]; /% Adressen der Bitplanen 1-6 */ 
UWORD pad7c[4)]; /%-%/ 
UWORD bplcon0; /* Blitter Kontrollregister 0 - ViewModi */ 
UWORD bpleoni; /* Blitter Kontrreg 1 - Scrolling pixelweise */ 
UWORD bplcon2; /* Blitter Kontrreg 2 - Videoprioritäten*/ 
UWORD pad83; /ж-%/ 
UWORD .bplimod; /* Modulo für ungerade BitPlanen */ 
UWORD bpl2mod; /* Modulo für gerade BitPlanen */ 
UWORD pad86[2];  /* - */ 
UWORD bpldat[6]; /% BitPlane (1-6) Daten %/ 
UWORD pad8e[2]; —/* - X/ 
АРТА sprpt[8]; /% Adresse der Spritedaten 1-8 */ 
struct SpriteDef[ 
UWORD pos; /* X/Y = Anfangsposition */ 
UWORD ctl; /* Y - Endposition */ 
UWORD dataa; /* WORD 1 der darzustellenden Sprite-Zeile */ 
UWORD datab; /* WORD 2 der darzustellenden Sprite-Zeile */ 
}spr[8]; /* die 8 Hardware-Sprites */ 
UWORD &olor[32]; · /* Farbregister 1-32 */ 
} 


Listing 1. Die Custom-Struktur vereinfacht 
den Zugriff auf die Custom-Register 


VOID MakeCList(y) 
SHORT y; 

[ 
if(yssOldY) return; 
CINIT(UCList,5) ; 
CWAIT(UCList,y-5,0); 
CMOVE(UCList, custom.color[0],NewCol) ; 
CWAIT(UCList,y45,0); . 
CMOVE(UCList,custom.color(0),01dCol); 
CEND(UCList); 
VPort->UCopIns=UCList; “ 
RemakeDisplay(); 
014Ү=у; 

) 


VOID main() 
( 


1f (classssMOUSEMOVE) [ 
MakeCList(Screen->MouseY) CloseW(); 


Listing 2. Eine veránderbare Copperliste 
muf vor jedem Neuaufbau reinitialisiert werden 


/ж 
ес CLIColor.c, +L 
1n CLIColor.o -1¢32 


\\ Gélzy's Copper Demo 
*/ 


#include <intuition/intuitionbase.h> 
#include <graphics/gfxmacros.h> 
#include <hardware/custom.h> 
#include <exec/memory.h> 

#include <exec/types.h> 

#include <functions.h> 
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Know-How 


NewWindow nwins[ 
0,0,225,10,-1,-1,CLOSEWINDOW, 
ACTIVATE WINDOWCLOSEI WINDOWDEPTHI WINDOWDRAG, 
NULL, NULL, (STRPTR) ”0812у!8 CLI-Color”, 
NULL, NULL, 0,0,0,0,WBENCHSCREEN 


IntuitionBase *IntuitionBase; 
GfxBase *GfxBase; 
UCopList *UCList=NULL; 
Screen *Sereen; 
Window “win; 

ViewPort *VPort; 


VOID CloseW() 


f 


) 


if(UCList){ 

FreeVPortCopLists(VPort) ; 

RemakeDisplay() ; 
} 
if (win) CloseWindow(win) ; 
if(GfxBase) CloseLibrary(GfxBase); 
if(IntuitionBase) CloseLibrary(IntuitionBase); 


VOID OpenW() 


1 


REGISTER SHORT 1; 


if(1(IntuitionBase=(struct IntuitionBase X) 
OpenLibrary(”intuition.library”,0))) 
if(!(GfxBase=(struct GfxBase *) 
OpenLibrary("graphics.library",0))) CloseW(); 
if(!(win=OpenWindow (&nwin))) C1oseW(); 
if(!(UCList=(struct UCopList X) 
AllocMem(sizeof(struct UCopList),MEMF. PUBLICI MEM 
F_CLEAR))) CloseW() ; 
Sereen=(struct Screen *) IntuitionBase->ActiveScreen; 
VPort =&Screen->ViewPort; 


CloseW(); 


ULONG GetMessage() 


{ 


] 


struct IntuiMessage *msg; 
ULONG class=0; 


if(msg=(struct IntuiMessage *)GetMsg(win-» UserPort))[ 
classsmsg-» Class; 


ReplyMsg(msg) ; 


return(class); 


VOID MakeCList() 


{ 


] 


REGISTER SHORT i,col=GetRGB4(VPort->ColorMap,0); 


for(i=0;i< 16;1++)[ 
CHAIT(UCList, 116,0) ; 
CMOVE(UCList, custom.color[0],col&ÜxFl (15-1)); 


CEND(UCList); 
VPort->UCopIns=UCList; 
RemakeDisplay(); 


VOID main() 


| 


1 


SHORT Quit=0; 
ULONG class; 


Openh(); 

MakeCList(); 

while(!Quit){ 
Wait(1< <win->UserPort->mp_SigBit); 
class=GetMessage(); 
if(class==CLOSEWINDOW) Quit=1; 

} 


CloseW(); 


Listing 3. Workbenchscreen 
muB Farbe bekennen: Copper-Demo »CLIColor« 


Rasantes Assemblerspiel mit Tücken 


Der Sturz ins 
denlose 


Ein antikes Sprichwort sagt: 
»Ob Holzleiter, Strickleiter, 


Abteilungsleiter oder 


Ráuberleiter - wer raufsteigt, 
kann auch runterfallen.« 


Von Hans Waldhäusel 


anz unten ist man 
schnell bei »Fast Fred- 
die«, einem neuen Ver- 


treter der bekannten und be- 
liebten - wenn auch schon et- 
was antiquierten -  Leiter-, 
Sammel-, Hüpfspiele. In As- 


sembler geschrieben, blitz- 
schnell und manchmal hunds- 
gemein. Mit gespeichertem 


Highscore, fetziger Musik und 
jeder Menge Gegner, die sich 
einen Spaß daraus machen, 
den armen Fred vom Gerüst zu 
schubsen. Fred ist Pazifist - er 
kann sich nicht wehren; schie- 
Ben ist nicht vorgesehen. Nur 
Schnelligkeit, Taktik und Reak- 
tionsvermögen führen zum 
Ziel. Bloß - dieses Ziel ist 50 Le- 
vel entfernt. 

Wir haben für Sie eine 
Bildschirm-Hardcopy abge- 
druckt (Bild 1), damit Sie sich 
beim Weiterlesen eine bessere 
Vorstellung von »Fast Freddie« 
machen können. Vorbild und 
Anregung für dieses Spiel holte 
sich der Michael Baumgaert- 
ner, der Programm-Autor, aus 
seligen 64er-Tagen - »Fast Ed- 
die« ist wohl jedem Umsteiger 
ein Begriff und die Namensver- 
wandtschaft kommt nicht von 
ungefähr. Hier, auf dem Amiga, 
muß der schnelle Fred in jedem 
Level mindestens neun von 
zehn möglichen Gegenständen 
einsammeln, erst dann darf er 
in den nächsten Level wechseln. 

Und auch dafür muß er sich 
noch plagen, da der Ausgang 
(ein Sprite namens »EXIT«) 
nicht stationär ist, sondern sich 
ebenfalls über den Bildschirm 
bewegt. Bei der Jagd nach den 
Gegenständen, die es einzu- 
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sammeln gilt, muß sich Freddie 
vor seinen Gegnern höllisch in 
Acht nehmen; die leiseste Be- 
rührung kostet ihn eines seiner 
fünf Leben. Für jeden gesam- 
melten Gegenstand gibt es 
Punkte, und bei Verlassen des 
Levels mittels »EXIT« (anstatt 
der etwas schmerzhafteren 
Schwerkraft-Variante - »Da ist 
kein Geländeeeeeeeeer...|«) 
gibt es zusätzlich 100 Bonus- 
punkte für jedes noch in Reser- 
ve stehende Leben. Emsiges 
Punktehamstern wird belohnt : 
bei 5000, 10000, 15000 usw. 
Punkten gibt es ein Extraleben. 
Aber Fred ist keiner von den 
Starken; mehr als sieben Re- 
serve-Leben kann er nicht mit- 
schleppen - schade! Aber 
schließlich kann man einem ar- 
men Wesen, das sich seine 
Punkte durch Laufen (Joystick 
links/rechts), Klettern (Joystick 
oben/unten) und Hüpfen (Feu- 
erknopf) erschuften muß, nicht 
auch noch einen Koffer auf den 
Rücken binden - oder ? 

Um »Fast Freddie« zu starten, 
öffnen Sie bitte ein CLI-Window 
- ein Start von der Workbench 
ist nicht möglich! Wechseln Sie 
in jenes Directory, in dem sich 
das Highscore-File »Hl« befin- 
det, also beispielsweise 


cd Freddie 


wenn Sie »Fast Freddie« und 
das Highscore-File in einem ei- 
genen Directory namens »Fred- 
die« abgelegt haben. Dann tip- 
pen Sie nach dem CLI-Prompt 
einfach 


FastFreddie 


und Ihrem Spielspaß steht 
nichts mehr im Wege. Nach 
kurzer Ladezeit befinden Sie 
sich im Start-Bild und bekom- 
men neben Stereo-Sound-den 


Bild 1. Auch nach einem steilen Aufstieg: Man ist schneller 


Sie übrigens durch Betätigen 
der Taste <m> ein- und aus- 
schalten können - auch die 
Highscore-Tabelle präsentiert 
(da können Sie sich gleich ein 
Ziel für den nächsten Durch- 
gang setzen). Nun liegt es an 
Ihnen, zu entscheiden, ob Sie 
durch Drücken des Joystick- 
Feuerknopfes in Level 0 begin- 
nen wollen oder ob Sie durch 
Eingabe eines Codeworts in ei- 
nen höheren Level einsteigen 
wollen bzw. dürfen. Diese Co- 
deworte erhalten Sie auf zwei 
Arten: Entweder Sie schum- 
meln und sehen im Source- 
Code nach (verwerflich, aber 
bequem) oder Sie verdienen 
sich die Kenntnis um diese Co- 
des, indem Sie sich durch die 
Level durcharbeiten (mühevoll, 
aber unterhaltsam). Jeweils 
nach Beendigung der Level 10, 
20, 30, 35, 40, 45 und 50 wird in 
der rechten unteren Bildecke ei- 
nes der besagten Code-Worte 
eingeblendet. Wenn Sie sich 


diese Codes merken, kónnen 
Sie bei Programmstart durch 
die erwáhnte Eingabe des je- 
weiligen Codes die einzelnen 
Level direkt ansteuern. 

Eines dieser Code-Worte 
wollen wir Ihnen hier verraten : 
»QUIT«! Damit beenden Sie das 
Programm (gemein, was?). Die- 
ses »QUIT« ist dann besonders 
wichtig, wenn Sie es geschafft 
haben, sich in der Bestenliste 
eintragen zu dürfen und diesen 
Erfolg der Nachwelt erhalten 
wollen - die Highscore-Abspei- 
cherung auf Diskette erfolgt 
nur, wenn Sie das Programm 
mit diesem Codewort verlassen. 

Irgendwo in der Mitte zwi- 
schen »spielen« und »Pro- 
gramm verlassen« liegt »Pau- 
se«; dankenswerterweise hat 
Michael Baumgaertner, der 
Programmautor, eine Pause- 
Funktion eingebaut. Sollte sich 
bei Ihnen Nanosekunden vor 
Erreichen des fünfundvierzig- 
sten Levels ein dringendes Be- 
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dürfnis einstellen, das Sie 
schon tapfer aber verzweifelt 
bis hierhin verschoben haben, 
so können wir Sie beruhigen: 
Drücken Sie die Taste <p> 
und der schnelle Fred und sei- 
ne Kontrahenten warten erstarrt 


auf Ihre Rückkehr. Sind Sie wie- 
der bereit und erleichtert, ge- 
nügt ein Druck auf <SPACE> 
und das Gemetzel geht weiter. 

Bevor wir zur Beschreibung 
des Quellcodes kommen, sollte 
eines zur allgemeinen Klarstel- 
lung gesagt sein: abzutippen 
gibt es nichts - oder kennen 
Sie jemanden, der bereit wäre, 
30 (in Worten: dreißig) Seiten 
Source-Code abzutippen? Ge- 
meint sind hier natürlich AMI- 
GA-Sonderheft-Listing-Seiten 
(zweispaltig, klein gedruckt, 
usw.). Und das wáre nur das 
Hauptprogramm! Die Daten für 
die einzelnen Level und die 
Sound-Files kämen noch dazu. 
Also wir, die AMIGA-Redaktion, 
haben beschlossen: NEIN! 
Spielspaß mit »Fast Freddie« 
gibt’s nur für Besitzer der Le- 
serservice-Diskette - wir glau- 
ben, damit im Sinne unserer 
Leser eine vernünftige Ent- 
scheidung getroffen zu haben. 
Dafür bieten wir Ihnen auch je- 
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de Menge Files in der Schubla- 
de »FastFreddie« und in deren 
Sub-Directories. 

Um spielen zu können, ge- 
nügt es, die Files »Fast Freddie« 
und »Hl« von der Leserservice- 
Diskette auf Ihre Spiele-Disket- 
te umzukopieren; der Rest ist 
nur für Programmierer und 
Source-Code-Schnüffler wich- 
tig. Bei dieser Gelegenheit 
noch eine Bemerkung zum 
Highscore-File »Hl«: »Fast Fred- 
die« prüft zwar, ob das File »Hl« 
erreichbar - sprich im aktuellen 
Directory zu finden - ist, nimmt 
es Ihnen aber auch nicht übel, 
wenn es das File nicht ent- 
decken kann und legt es in die- 
sem Fall auch nicht neu an. Ei- 
ne »pro forma«-Highscore-Ta- 
belle ist nämlich im Programm 
integriert, und die wird dann 
auch angezeigt. Sie können 
sich in diese Liste sogar eintra- 
gen - aber der nächste Reset 
läßt Sie dann erleben, wie ver- 
gänglich Ruhm sein kann. 


Listing - 
nein danke? 


Sollten Sie, ganz gleich, aus 
welchem Grund, die Source- 
Files neu assemblieren wollen, 
beachten Sie bitte folgendes: 
geschrieben wurde das Pro- 
gramm für und mit dem »PRO- 
FIMAT« von Data-Becker. Soll- 
ten Sie noch eine Version die- 
ses Assembler-Pakets besit- 
zen, die den Befehl »even« nicht 
implementiert hat, so ersetzen 
‚Sie bitte sowohl im File »Fast- 
Freddie.src« als auch in »Hl.src« 
die dort vorkommenden »even« 
durch »align.w«. Mit dem einge- 
bauten Editor ist das ja kein gro- 
Ber Aufwand. Sie müssen dazu 
aber den für den Editor reser- 
vierten Speicherbereich ver- 
gróBern (200000 Byte ist ein 
schóner, runder Wert). Beim 
Assemblieren stellen Sie bitte 
alle drei Auswahlfelder (SOUR- 
CE, DATA und BBS) auf »CHIP«. 
Ganz wichtig: das Hauptpro- 
gramm »FastFreddie.src« as- 
semblieren Sie mit der Einstel- 
lung »normaler Code«; für die 
Generierung des Highscore- 
Files »Hl« und der Hilfsdateien 
»Levelst« und »Levels2« müs- 
sen Sie bei der Assemblierung 
von »Hl.src«, »Levelst.src« und 
»Levels2.src« unbedingt auf 
»absoluter Code« stellen! Für 
die Assemblierung des Haupt- 
programms ist auch wichtig, 
daß Sie die externen Files in ih- 
ren Directories (»gfx«, »sprites« 
und »music«) belassen - die je- 
weiligen Pfadangaben sind im 
Hauptprogramm festgelegt. 


»FastFreddie ist nicht multi- 
taskingfáhig - aber welches 
schnelle Action-Spiel ist das 
schon? Die Eingaberoutine für 
die Highscore-Eintragungen ist 
auch gerade keine Textverar- 
beitung (vertippen Sie sich bloß 
nicht!). 


Ein Tip von Fred 


Aber einen kleinen Trick, der 
in diesem Programm zur An- 
wendung kommt, wollen wir Ih- 
nen doch etwas näherbringen. 
Wenn Sie erst ganz am Anfang 
Ihrer Assembler-Laufbahn auf 
dem AMIGA stehen, liegt der 
Verdacht nahe, daß Sie für das 
Löschen bestimmter Speicher- 
bereiche den 68000er werken 
und in einer Schleife die Null- 
Bytes in den Speicher quet- 
schen lassen - da bleibt für an- 
dere Dinge natürlich entspre- 
chend weniger Zeit, und allzu 
schnell geht das auch nicht. 
Dabei drängt sich für solche Ak- 
tivitäten, also wenn es um groß- 
flächige Byte-Füllereien geht, 
einer der AMIGA-Co-Prozesso- 
ren geradezu auf: der soge- 
nannte Blitter. 

Der »Blitter« sitzt wie ein Un- 
termieter gemeinsam mit dem 
»Copper« auf jenem Silizium- 
chip, dem sein Entwickler Jay 
Miner den Namen »AGNUS« 
gab (»Fat Agnus« und der neue, 
1 MByte Chip-Memory verwal- 
tende »Super Agnus« sind Wei- 
terentwicklungen). Blitter steht 
für »BLock Image TransfER 
(das zweite »T« ist während der 
Jahre, die dieses Miniatur-Ma- 
schinchen jetzt schon auf dem 
Buckel hat, sprachlich »dazu- 
gewachsen«). Aus dieser Be- 
zeichnung läßt sich bereits er- 
kennen, wofür dieser Chip-Teil 
in erster Linie entworfen wurde 
und wo daher naturgemäß sei- 
ne Stärke liegt: den Inhalt eines 
Speicherblocks manipulieren 
und in einen anderen übertra- 
gen. Und das, weil hardware- 
codiert, in blitzartiger Ge- 
schwindigkeit - ein gern zitier- 
tes Beispiel für die Geschwin- 
digkeit des Blitters ist das 
Zeichnen von Linien mit einer 
Million Punkten pro Sekunde. 

Nun ist das Löschen eines 
Speicherbereichs eigentlich 
auch nur das Kopieren eines 


oder mehrerer Null-Bytes in - 


den zu löschenden Bereich, 
und dazu ein Beispiel, wie man 
es »auch« machen kann: 

a) als erste Aktion steht »keine« 
Aktion auf dem Programm. Es 
heißt warten, bis der Blitter mit 
der soeben laufenden Aktivität 
fertig ist. 
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b) Blitter in den Kopier-Modus 
schalten und DMA-Kanal für 
Ziel »D« einschalten 
с) Anfangsadresse des zu ló- 
schenden Bereichs als Ziel- 
adresse deklarieren 
d) als »Quelle« wird »A« verwen- 
det und mit dem gewünschten 
Wert, hier also »NULL«, be- 
schrieben 
ei Nun den Modulo-Wert für 
Ziel D = 0 
f)Maskierung des Bereichs 
ausschalten 
9) Blitter-Sonder-Modi 
schalten 
h) GróBe des gewünschten - zu 
lóschenden - Bereichs ange- 
ben. Die Bereichsgröße ist als 
rechteckiges Feld anzugeben 
und ergibt sich aus »Größe = 
Höhe x 64 + Breite in Worten«. 
Als Assembler-Quelltext liest 
sich das dann so : 


aus- 


wait: 
BIST #14,$DFF002 za) 
BNE wait 
MOVE.w #%00000001 
11110000, $DFFO40 ;b) 
MOVE.1 #Adresse, 
$DFFO54 36) 
CLR.w X $DFFO74 ;d) 
CLR.w _$DFF066 ;e) 
MOVE.w #-1, 
$DFF044 3£) 
MOVE.w #-1, 

$DFFO46 ыр) 
CLR.w $DFFO42 ;g) 
MOVE.w #Größe, 
$DFFO58 ;h) 
RTS 


Diese Routine ist besonders 
bei groBen zu bearbeitenden 
Speicherfeldern wesentlich 
schneller als die oben genann- 
te Schleife des Hauptprozes- 
sors. Überdies kann der 
68000er weiterarbeiten, wäh- 
rend der Blitter das Datenfeld 
löscht. Stark bemerkbar macht 
sich dieser Vorteil dann, wenn 
der Prozessor im FAST-Memo- 
ry weiterarbeiten kann, weil er 
sich dann den Daten-Bus nicht 
mit dem Blitter zu teilen 
braucht. 

Soweit zum Spezial-Tip von 
Michael Baumgaertner. Auch 
zu »Fast Freddie« wäre alles 
Wesentliche gesagt. Also dann: 
rauf auf die Leitern - und lassen 
Sie sich (und Freddie) nicht er- 
wischen! so 


Hans Waldháusel kam als Programmierer vom 
128er zum Amiga. Sie erreichen ihn über unse- 
re Verlagsanschrift (Markt&Technik Verlag 
AG, Redaktion Sonderhefte, z.Hd. Herrn 
Waldháusel, Hans-Pinsel-StraBe 2, 8013 Haar). 
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Von Hans Waldhäusel 


ür diejenigen, die noch 
nicht wissen, was ge- 
meint ist, haben wir das 
Bildschirmfoto eines der Spiel- 
felder abgebildet (Bild 1). Jetzt 
hat's aber geklingelt! Im Ge- 
gensatz zum Vorbild bietet 
»SCHIEBESPIELCHEN« ver- 
schiedenste Arten von Spielfel- 
dern. Arabische und römische 
Ziffern, Bildteile anstelle von 
Ziffern (fast schon ein Puzzle) 
und unterschiedliche Anzahlen 
von Schiebeplättchen stehen 
bereit, Ihnen beim Sortieren die 
Haare zu Berge stehen zu las- 
sen. 
Highscore-Speicherung und 
komfortable Mausbedienung 


sind selbstverständlich. Natür- 
lich übernimmt der Computer 
die »Anfangs-Chaotisierung« 
des Spielfeldes. Und auch 
wenn es manchmal nicht so 
aussehen mag - jedes Spiel ist 
lösbar! 

Starten Sie das Programm 
entweder durch Anklicken des 
Icons oder, wenn Sie Amiga- 
Basic schon geladen haben, 

. durch Eingabe von 


run”SCHIEBESPIELCHEN_ 
v1.4” 


Nach dem Start des Pro- 
grammes wählen Sie einen der 
drei zur Verfügung stehenden 
Spielmodi. 

Die vermutlich am meisten 
gespielte Variante ist »Normal« 
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(warum hat der Programm- 
Autor sie wohl so genannt?), 
bei der es darauf ankommt, 
die durcheinandergebrachten 
Schiebeplättchen mit möglichst 
wenig Zügen in die richtige Rei- 
henfolge zu bringen. Positionie- 
ren Sie den Mauszeiger über 
dem entsprechenden Feld und 
klicken Sie mit der linken Maus- 
taste. Im darauf eingeblendeten 
Auswahl-Bild entscheiden Sie 
sich für eines der sechs vorge- 
gebenen Spielfelder (Tabelle 1). 
»Elefant« und »Auto« sind puzz- 
leähnlich aufgebaute. Spielfel- 
der, während die anderen vom 
Prinzip her dem »Original« glei- 
chen, auch wenn der Redak- 
tion kein Original mit 48 Feldern 
(Megabild) bekannt ist- kennen 
Sie eines? 


Bild 1. Das ist die Oberfläche von »SCHIEBESPIEL« für den AMIGA 


Nach dem Anklicken des ge- 
wünschten Spielfeldes wird das 
entsprechende Bild von Disket- 
te nachgeladen und vom Com- 
puter präpariert. Bei der Prápa- 
ration kónnen Sie zusehen - als 
mitfühlender Zeitgenosse hat 
Guido Kensche, der Programm- 
Autor, »nur« 400 bis 1000 Ver- 
tauschungen als Startvorgabe 
gewählt. Nach Abschluß der 
Vertauschungen werden Sie 
durch ein eingeblendetes Fen- 
Ster aufgefordert, mittels Maus- 
klick (links) den Wettstreit zu er- 
öffnen. In der Abbildung sehen 
Sie im oberen Bildschirmbe- 
reich eingeblendet die verstri- 
chene Zeit und die Anzahl der 
bisher getátigten Verschiebun- 
gen. In der rechten Bildhálfte 
Sind zwei Gadgets angeordnet: 
»PAUSE« und »Aufgeben«. Im 
Falle, daß der Frust Sie über- 


Sicher kennen Sie die Schieberei 


Seit den fünfziger Jahren 
dieser Geduldsspiele nichts geänd 


Standard 1 
Standard 2 
Megabild 
Elefant 
Auto 
Klassik 


Spielfelder 


Hier ist endli 


Amiga. Sobald Sie alle Felder in 
die richtige Reihenfolge ge- 
bracht haben, gelangen Sie au- 
tomatisch in das Anfangsmenü. 
Sollten Sie es gar geschafft ha- 
ben, einen der fünf Highscores 
zu knacken, dürfen Sie sich zu- 
vor noch in der Bestenliste ein- 
tragen. 


Highscore 
geknackt 


Eine andere Art, an die Sa- 
che heranzugehen, ist Modus 2 
- »Zeitspiel - 1 Spieler«. Die zu 
lósenden Bilder sind die glei- 
chen, aber jetzt gilt es, eine 
Zeitvorgabe zu unterbieten. 
Den Zeitrahmen béstimmen 
Sie selbst, und zwar zwei, fünf 
oder zehn Minuten. 

Als besonderen Anreiz kón- 
nen Sie auch gegen den Be- 
sten der jeweiligen Highscore- 
Liste antreten, dessen Zeit 


4x 4 Felder 
5 x 5 Felder 
6 x 8 Felder 
4x 4 Felder 
4x 4 Felder 
6 x 5 Felder 


Tabelle 1. Sechsfacher Spaß mit SCHIEBESPIEL 


mannt und Sie »Aufgeben« an- 
klicken, werden Sie ins Haupt- 
menü zurückgeschaltet. »Pau- 
se« ist nur zum Ausruhen ge- 
dacht, nicht aber zum Schum- 
meln! »Pause« anklicken und 
dann bei angehaltener Stopp- 
uhr in Ruhe nachdenken wollen 
gilt nicht - das Spielfeld wird ab- 
gedeckt (ätschl). Verschieben 
Sie die Felder einfach durch An- 
klicken, den Rest macht Ihr 


dann als -Limit übernommen 
wird. Damit Sie sich nicht unab- 
sichtlich übernehmen, wird die 
jeweilige Highscore-Liste vor- 
her angezeigt. Während des 
Spieles läuft die eingeblendete 
Stoppuhr als Count-Down-Zäh- 
ler. 

Bleibt noch die dritte Spielva- 
riante: »Zeitspiel - 2 Spieler«. 
Hier wird die Zeit, die der erste 
Spieler für die Lösung braucht, 
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die Zeit 


183/182 
CNTR = 


183/68 


nit 15 Plattchen Uber 16 Felder. 
ich an Prinzip und Aufbau 
-Kunststoffplattchen und Ziffern. 
lie zeitgemäße Version. 


gepatchte Version von Amiga- 
Basic in das Root-Directory 
(zum PAL-Patch lesen Sie wei- 
ter unten mehr); 

f)laden und starten Sie das 
Programm »HIGHSCORE-ER- 
STELLEN«; 

g) laden und starten Sie das 
Programm »SCHIEBESPIEL_ 
V1.4«; 

h) spielen Sie und staunen Sie! 


Die Arbeit 


Die eigene Spiel-Diskette ist 
deshalb empfehlenswert, weil 
durch die Möglichkeit der High- 
score-Speicherung der Schreib- 
schutz der Diskette keinesfalls 
eingeschaltet sein darf. Das 
Programm prüft den Schreib- 


412/182 


511/157 


511/124 


472/68 


Die hell eigerahnten Bereiche werden yon Progrann abge- 
fragt und nanipuliert. Die angegebenen Koordinaten der 
Eckpunkte der Rechtecke wurden nit dPaint III in Med- 

Res-Modus ernittelt, 


Bild 2. Die von SCHIEBESPIEL bearbeiteten Bild-Bereiche 


zur Vorgabe für den zweiten, 
die dieser zu unterbieten hat. 

Zwei Punkte im Hauptmenü 
wurden noch nicht erwáhnt: 
»Highscore ansehen« und 
»QUIT« - Erláuterungen hierzu 
sind wohl überflüssig. Und wer 
tatsächlich eine Anleitung 
braucht, für den wird eine sol- 
che eingeblendet, wenn er im 
Hauptauswahl-Menü in das Ti- 
telfeld klickt. 

Um in den Genuß des Spiel- 
vergnügens mit SCHIEBE- 
SPIELCHEN zu kommen, gibt 
es für Sie zwei Möglichkeiten: 
tippen oder kaufen. Falls Sie 
sich für »kaufen« entschieden 
haben und jetzt stolzer Besitzer 
der Leserservice-Diskette zu 
diesem Sonderheft sind, gehen 
Sie bitte folgendermaßen vor: 
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a) formatieren Sie eine leere 
Diskette; 

b) kopieren Sie soweit als not- 
wendig Directories und Files 
von Ihrer Workbench-Diskette 
(je nachdem, ob Sie von Ihrer 
SCHIEBESPIELCHEN-Disket- 
te auch booten wollen oder 
nicht); 

с) in das Directory »libs« kopie- 
ren Sie zusátzlich die ».bmap«- 
Dateien »dos.bmap«, »exec. 
bmap«, »graphics.bmap« und 
»intuition.bmap«. Auch die 
»icon.library« muß vorhanden 
sein. 

d) kopieren Sie den Inhalt (!) der 
Schublade »SCHIEBESPIEL- 
CHEN« von der Leserservice- 
Diskette auf Ihre Spieldiskette 
(auch die Sub-Directories!); 

е) kopieren Sie eine auf PAL 


schutz-Status und verweigert 
Ihnen den Spielspaß, wenn der 
Schreibschutz aktiviert ist! 

Sie wollen (oder kónnen) die 
Leserservice-Diskette nicht 
kaufen? Dann steht Ihnen jede 
Menge Arbeit bevor. Das 
Hauptprogramm (Listing 1) und 
den Highscore-Maker (Listing 
2) müssen Sie auf jeden Fall ab- 
tippen. Die Spielfelder müssen 
Sie sich selbst zeichnen - oder 
wollten Sie eine DATA-Wüste 
vorgesetzt bekommen? - Na 
eben. Als Anhaltspunkt und 
kleine Hilfe für die Bildgestal- 
tung haben wir zwei Bilder ab- 
gedruckt (Bild 2 und Bild 3), die 
bereits auf die richtigen MaBe 
»zurechtgestutzt« sind. »Schie- 
bespiel« lädt zu Beginn das Bild 
»HAUPTMENU« und schreibt in 
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dieses Bild die Auswahlmög- 
lichkeiten. Welcher Bereich 
vom Programm beschrieben 
wird, entnehmen Sie bitte Bild 3 
- der rot umrandete Bereich 
wird sowohl bei der Auswahl 
des Spielmodus als auch des 
Spielbildes für die Aus- und Ein- 
gabe verwendet. Die einge- 
blendeten Koordinaten sollen 
Ihnen die Orientierung erleich- 
tern. Die Spielfelder selbst ha- 
ben für alle Modi die gleiche 
Bildeinteilung. In Bild 2 haben 
wir die vom Programm bearbei- 
teten Bereiche eingerahmt und 
die Eckpunkte, soweit nótig, 
vermaßt. Alles, was Sie in den 
groBen Mittelbereich zeichnen, 
wird von »SCHIEBESPIEL« au- 
tomatisch zerschnippselt und 
verschoben. Die beiden kleinen 
Rechtecke rechts vom Spielfeld 
werden auf Mausklick abge- 
fragt. Der Bildinhalt selbst ist für 
das Programm völlig irrelevant 
- Ihrer Fantasie und Ihrem 
Geschmack sind keine Gren- 
zen gesetzt. Wichtig bei der 
ganzen Sache ist nur, daB Sie 
für jedes Bild genau den Na- 
men verwenden, den das Pro- 
gramm und der »HIGHSCORE- 
MAKER« erwarten (siehe Tabel- 
le 2), und daß Sie die Bilder vom 
IFF- in das ACBM-Format kon- 
vertieren. 

Warum konvertieren? IFF ist 
zwar als Standard-Format für 
Bilder und Sounds allgemein 
anerkannt, läßt sich von Basic 
aus aber langsamer laden als 
ein im ACBM-Format vorliegen- 
des File und braucht auch mehr 
Platz auf der Diskette. Die Lade- 
routine von »Schiebespiel- 
chen« verlangt nach ACBM- 
Dateien, und daher muß jedes 
von Ihnen gemalte Bild mit dem 
Basic-Programm . »LoadILBM- 
SaveACBM« umgewandelt wer- 
den. Dieses Konvertierungs- 
programm finden Sie auf der 
»EXTRAS«-Diskette im  Ver- 
zeichnis »BASIC-DEMOS«. 

Allerdings ist, ebenso wie bei 
Amiga-Basic, noch ein kleiner 
Patch notwendig - dazu spáter 
mehr. Unbedingt brauchen Sie 
das Bild »HAUPTMENU« und 
eines der Spielfelder. 

Zur besseren Übersicht ha- 
ben wir alle mit SCHIEBE- 
SPIELCHEN in Verbindung ste- 
henden Files und Directories in 
Tabelle 2 zusammengefaBt. Es 
wird immer nur das im Haupt- 
menü angewáhlte Spielfeld ge- 
laden, so daß bei Nichtvorhan- 
densein eines Bild-Files nicht 
mehr passiert, als daB Sie eine 
Fehlermeldung geschenkt be- 
kommen. 

Dies als kleiner Tip für alle, 
die nicht gleich »die volle Latte« 
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zeichnen und malen wollen. 
Für das komplette Spiel sind fol- 
gende Dateien zusätzlich zu 
»HAUPTMENU« zu malen und 
mit exakt dem angegebenen 
Namen zu speichern: »AUTO«, 
»KLASSIK«, »ELEFANT« - das 
soll ein »Ottifant« sein - Otto 
möge uns verzeihen, »STAN- 
DARD«, »STANDARD Il« und 
»MEGABILD«. 

Die Filenamen werden so- 
wohl vom Hauptprogramm als 
auch vom Highscore-Maker 
verwendet - bitte keine leicht- 
fertigen Experimente! 

Nach dem Abtippen der Li- 
stings 1 und 2 verfahren Sie 
ebenso wie die Besitzer der 
Programmservice-Diskette von 
a) bis e). 

Anstelle des Kopiervorgan- 
ges in Punkt d) legen Sie ein Di- 


Directory File 


Files und Directories 


es der amerikanischen NTSC- 
Norm entspricht. Im AMIGA- 
Sonderheft 1 wurde ein kleines, 
Patchprogramm veröffentlicht, 
mit dem dieses Manko ausge- 
glichen werden kann. SCHIE- 
BESPIELCHEN braucht diese 
gepatchte Version. Für diejeni- 
gen, die weder das Sonderheft 
1 noch eine bereits modifizierte 
Version von Amiga-Basic besit- 
zen, hier noch einmal die Vor- 
gangsweise (die Patches stam- 
men übrigens von Peter Pórner 
und Alexander Wagner). 


' Patches 


Das in Listing 3 abgedruckte 
Basic-Programm »HóhenPatch« 
nimmt Ihnen die Arbeit ab. In 
der vorliegenden Version ist es 
nur auf jene Basic-Versionen 


Listing # Bemerkung 


Root SCHIEBESPIELCHEN. V1.4 Listing 1 

Root HIGHSCORE-ERSTELLEN Listing2 rr 
libs dos.bmap T 

libs exec.bmap * 

libs graphics.bmap Ы 

libs intuition.bmap * 

libs icon.library " 

BILDER HAUPTMENU 

BILDER AUTO 

BILDER KLASSIK 

BILDER ELEFANT 

BILDER STANDARD 

BILDER STANDARD II 

BILDER MEGABILD 

Root АтідаВавіс A 

Root HöhenPatch Listing 3 ** 
IFF MEGABILD.pic 7% 


Tabelle 2. Dateien für SCHIEBESPIEL. Die mit »*« 
bezeichneten Dateien sind nicht auf der Leserservice- 
Diskette enthalten. Dateien mit der Kennung »* werden 
beim Spielen nicht benötigt. 


rectory »BILDER« an und spei- 
chern die konvertierten Bilder in 
diesem Sub-Directory. Die Files 
»Schiebespiel V1.4« aus Listing 
1 und »HIGHSCORE-ERSTEL- 
LEN« aus Listing 2 legen Sie im 
Stammverzeichnis ab, ebenso 
die gepatchte Amiga-Basic-Ver- 
sion. Laden Sie Amiga-Basic 
und starten Sie das Programm 
»HIGHSCORE-ERSTELLEN«. 
Der Highscore-Maker legt im 
Sub-Directory »HIGHSCORE« 
die notwendigen Files an. 

Das Ausgabefenster von Ami- 
ga-Basic ist in keiner der bis da- 
to serienmäßig ausgelieferten 
Versionen in der Lage, den vol- 
len PAL-Bildschirm auszunüt- 
zen - anstelle der zur Verfü- 
gung stehenden 256 vertikalen 
Bildschirmpunkte können nur 
200 angesprochen werden wie 
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anwendbar, die 103484 Byte 
oder 103500 Byte lang sind. 
Kontrollieren Sie bitte vorsichts- 
halber Ihre Version auf die rich- 
tige File-Länge mit dem LIST- 
Befehl und verwenden Sie für 
die Modifikation keinesfalls 
das Original, sondern eine Ar- 
beitskopie: 


list АпіраВавіс 


Wenn die oben genannten 
File-Längen mit Ihrer Amiga- 
Basic-Version übereinstimmen 
(und Sie Listing 3 abgetippt ha- 
ben), können Sie loslegen. La- 
den und starten Sie Amiga-Ba- 
sic und das Programm »Höhen- 
Patch«. Nach Ende des Pro- 
grammlaufes kontrollieren Sie 
wieder mit dem »list«-Befehl, ob 
die Filelänge noch die gleiche 
wie im Original ist (sicher ist si- 


Schiebes 


©1989 by espe 


lẹ 


49/165 


in rot unrandeten Bereich erfolgt die 


Bild 3. Für die Abfrage während der Spiel-Auswahl wird 


cher). Wenn ja, haben Sie jetzt 
genau die BASIC-Version, die 
SCHIEBESPIELCHEN braucht. 
Wenn nicht, haben Sie irgend- 
wo Blódsinn gemacht - fróhli- 
ches Suchen. 

Es gibt aber noch eine veróf- 
fentlichte Amiga-Basic-Version 
(V1.0), deren File-Lánge nicht 
mit den obengenannten Byte- 
Zahlen übereinstimmt. Sollte 
Ihr Amiga-Basic-File eine Län- 
ge von 93156 Byte haben, kón- 
nen Sie mit zwei kleinen Modifi- 
kationen das Patchprogramm 
aus Listing 3 verwenden: Die 
Zahl »&H57ec« muB durch 
»&H55e8 ersetzt werden, die 
Zahl »&H5c00« ist durch 
»&H2800« zu ersetzen. 

Soweit zu Amiga-Basic. Das 
Konvertierungsprogramm 
»LoadILBM-SaveACBM« von 
der »EXTRAS«-Diskette muß al- 
lerdings auch noch an die volle 
PAL-Höhe angeglichen wer- 
den. Dazu laden Sie Amiga-Ba- 
sic und das Konvertier-Pro- 
gramm und ersetzen in Zeile 

279 (Leerzeilen mitgezählt!) 

IF scrHeight% >200 

then kk = kk+2 

die Zahl 200 durch die Zahl 256, 
so daß es jetzt heißen muß: 
IF scrHeight% >256 

then kk = kk+2 

Jetzt ist auch der Konverter fit 
für unser Spiel. 

SCHIEBESPIELCHEN ist ei- 
ne überzeugende Demonstra- 
tion dafür, was aus dem als 


langsam verrufenen Amiga-Ba- 
sic herauszuholen ist, wenn 
man die Betriebssystem-Routi- 
nen konsequent einsetzt. Die 
Verschiebungen, die der Com- 
puter zu Beginn jedes Spieles 
vornimmt, finden tatsächlich 
grafisch auf dem Bildschirm 
statt, auch wenn es wegen der 
enormen Geschwindigkeit wie 
Geflimmer aussieht! Aber es 
Stecken noch andere erwáh- 
nenswerte Besonderheiten in 
diesem Programm - einige da- 
von seien hier stellvertretend 
für alle kurz angerissen: 


Feinheiten 


Amiga-Basic ládt bekanntlich 
Bilder, die im ACBM-Format 
vorliegen, schneller als solche 
im IFF-ILBM-Format. Auf der 
mit Ihrem Rechner mitgeliefer- 
ten Extras-Diskette finden Sie 
ein Basic-Programm zum La- 
den von ACBM-Files, genannt 
»LoadACBM«. Dieses  Pro- 
gramm ist knapp 200 Zeilen 
lang und braucht für das Laden 
des Files »STANDARD« etwas 
mehr als sechs Sekunden. Die 
in diesem Programm verwen- 
dete Laderoutine ist auf die An- 
wendung zurechtgestutzt, mit 
weniger als 90 Programmzeilen 
deutlich kürzer und überdies et- 
was schneller (Ladezeit für 
»STANDARD« unter fünf Sekun- 
den). Wenn Sie in Ihren Pro- 
grammen nicht alle Fáhigkeiten 
von »LoadACBM« brauchen - 
abkupfern erlaubt. 
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frage ! 


der rot umrandete Teil verwendet 


Professionell gemacht ist 
auch der »Custom-Guru«, der 
immer dann eingeblendet wird, 
wenn ein Fehler auftritt, den 
das Programm nicht ausglei- 
chen kann (z.B., wenn die Dis- 
kette schreibgeschützt ist). Sie 


! Programm: Schiebespiel 


finden die Subroutine, die die 
Betriebssystem-Routine »Dis- 
playAlert« einsetzt, zwar auch 
am Ende des Programmes un- 
ter dem Label »Alarm«, der bes- 
seren Übersicht halber haben 
wir den Block noch zusätzlich 
herausgelöst, um Ihnen das 
Einbinden in Ihre Programme 
zu erleichtern: 


SUB Alarm(anz%,T$(), 
Height%) STATIC 
ап2%-ап2%-1 : type%= 
0°: А1$=”” 

FOR 1%-0 TO anz% 
Y%(1%)=1%*12+15 
X%=320-4*LEN(T$(I%) ) 
A1$=A1$+MKI$ (X4) +CHR$(Y% 
(1%) )+T$(1%)+CHR$ (0) 

IF I%ahz% THEN А1$=А1$+ 
CHR$(1) ELSE А1%-А1%- 
CHR$(0) 

NEXT 1% 

CALL DisplayAlert(type%, 
SADD(A1$) ‚Height%) 

END SUB 
Schreibschutzfehler: 
'wenn Diskette nicht 
Write-enabled ist 
Mess$(0)- "Fehler 
aufgetreten..." 
Mess$(1)=Bie Diskette 
muß Write-enabled 
(Schreibschutz auf) 
sein,” 

Mess$(2)="da der 


(c)1989 Guido Kensche 


' ` letzte Änderung: 6.7.89 


WINDOW 1, ”Schiebespielchen - 1989 Guido Kensche...”,(0,0)-(631,242) ,0 


CLEAR ,40000& 


ON BREAK GOSUB Keine.Unterbrechung 
' <~ hier muß später BREAK ON hin 
ON ERROR GOTO Schreibschutzfehler 


BREAK OFF 


ШЕ 


Deklarationsteil, Eröffnung der Bibliotheken *#** 


DIM Bitplane&(5), cTabWork%(32), cTabSave%(32) 


DECLARE FUNCTION xOpen& LIBRARY 
DECLARE FUNCTION xRead& LIBRARY 
DECLARE FUNCTION xWrite& LIBRARY 


DECLARE FUNCTION AllocMem&() LIBRARY 


LIBRARY ”:1ibs/dos.library” 


Highscore gespeichert 
wird 111” 
Alarm 3,Mess$(),50 


Es handelt sich hier um einen 
sogenannten »Recoverable 
Alert«, also um eine Alarm-Mel- 
dung, die nicht zwangsläufig 
zum Programmabbruch führt, 
sondern bei der nach Drücken 
der Maus-Taste eine Fortset- 
zung des aufrufenden Pro- 
gramms möglich ist. Der Ein- 
sprungpunkt ist das Label 
»Schreibschutzfehler«, das der 
Einfachheit halber aus dem 
»ON ERROR GOTO«-Komman- 
do heraus angewählt wird. Da 
das Betriebssystem bei Aufruf 
einer Alert-Meldung den auszu- 
gebenden Text in einem Array 
erwartet, wird zuerst der ge- 
wünschte Text dem Array 
»Mess$« zugewiesen. Unmittel- 
bar danach erfolgt der Aufruf 
des Unterprogramms »Alarm«. 
Als Parameter werden überge- 
ben: »3« als Anzahl der auszu- 
gebenden Text-Array-Felder (0 
bis 2), »Mess$()« als Information 
für das Betriebssystem, wel- 
ches Array zu verwenden ist, 
und zu guter Letzt noch »50« als 
Höhe der Alert-Box in Pixel. 
Diese Routine ist übrigens eine 
»Untermenge« einer in AMIGA- 
Sonderheft 3 vorgestellten, dort 
aber allgemeiner gehaltenen 
Alert-Routine, die im Rahmen 
des Basic-Kurses »Amiga-Basic 


Hauptmenue.eins: 


SPIELE 


im Höhenflug« veröffentlicht 
wurde (was, Sie haben dieses 
Sonderheft nicht? Ein schwerer 
Fehler, aber keine Angst, es 
kann noch nachbestellt werden). 
Für alle, denen die vorliegen- 
den Spielfelder nicht ausrei- 
chen, haben wir auf der Leser- 
service-Diskette im Directory 
»IFF« das File »MEGABILD.pic« 
abgelegt. So brauchen Sie sich 
nicht mit Konvertierungen ab- 
zuplagen, wenn Sie Ihr eigenes 
Spielfeld in SCHIEBESPIEL- 
CHEN integrieren wollen (geht 
übrigens ganz einfach - aber 
denken Sie an den HIGH- 
SCORE-MAKER). 


Eine nette Sache wäre, be- 
sonders für Anfänger, eine ein- 
stellbare Anzahl von Vertau- 
schungen zu Beginn des 
Spiels. Anbieten würde sich 
das Feld links vom Verschiebe- 
bereich, das noch nicht genutzt 
wird. Es würde genügen, die 
DATA-Werte für die Anzahl der 
Vertauschungen im Block »*** 
Bilderdaten *« zu manipulieren, 
bzw. den Befehl »READ Ver- 
tausch« durch das Einlesen ei- 
ner Variablen zu ersetzen. 

Das war's - wir wünschen 
Ihnen stundenlanges Vergnü- 
gen! so 


' Ansprung, wenn Aufgegeben angeklickt wurde 


Lade.Bild "Bilder/HAUPTMENÜ",Lesefehler$ 
IF Lesefehler$< >”” THEN Fehler.in.Bilddatei 


Hauptmenue: 
COLOR 1,3 : COLOR 0,2 : 


Hilf=MOUSE(0) 


LOCATE 11,9 : Prnt "Zuerst müssen Sie den Spielmodus wählen 


(anklicken)...” 
LOCATE 13,9 : Prnt "Normal - 
gezühlt, die Zeit" 


Anzahl der Verschiebungen wird 


LOCATE 14,21: Prnt "dient nur zur Information. Ziel ist es, mit" 
LOCATE 15,21: Prnt "wenig Vertauschungen das Bild zu sortieren" 


LOCATE 17,9 : Prnt "Zeitspiel - 


eine vorgewühlte Zeit ist zu schlagen, ” 


LOCATE 18,8 : Prnt "(1 Spieler) 
Belang..." 


Vertauschungszahl ist hier ohne 


LOCATE 21,9 : Prnt "Zeitspiel - Spieler 1 gibt eine Zeit vor, die 


von Spieler 2” 
LOCATE 22,8 : Prnt "(2 Spieler) 


unterboten werden muß...” 


LOCATE 23,21: Prnt "Sieger ist der Schnellere 111” 
LOCATE 25,9 : Prnt "HIGHSCORE - ansehen der Best-Plazierten pro 


Bild..." 


LIBRARY ":libs/exec.library" 
LIBRARY ":libs/graphics.library" 
LIBRARY ":libs/intuition.library" 


DEFINT Win, Sek, X, X2,X3, Y, Y2, Y3, XP4xe1  Vertausch, Xnove, XMovanz, 
Zufall, I 

DIM Wert(8,6), ZFe1d(3204) 

RANDOMIZE TIMER 


' жж testet, ob Schreibschutz offen ist, für Highscore *** 
Anfang: 

OPEN ":Test" FOR OUTPUT AS #1 

CLOSE 


' ***  Hauptmenue, Auswahl des Spielmodus Жж 
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LOCATE 27,14: Prnt "QUIT - raus-auf die Workbench” 


WHILE MOUSE(0)« 1 OR (Spielmodus« 0 AND Spielmodus < >-2) OR 
Spielmodus>4 
Y=PEEKW(WINDOW(7)+12) 
Spielmodus=-INT((Y-104)/32)*(Y<213)-(Y>212)*4 
IF Spielmodus<>X AND Х>-1 AND Х<5 THEN 
LINE (52,X%32494+(X=4) #16) -(550,X*32+120+(X=3) #16+(X=1) *8+ 
(X24)*32) ,2,b 


Listing 1. Das Hauptprogramm 
SCHIEBESPIELCHEN. V1.4. 


END IF 

IF Spielmodus>-1 AND Spielmodus<5 THEN 
X2=(Spielmodus=3)*16+(Spielmodus=1)*8+(Spielmodus=4)*32 
LINE (52,Spielmodus*32+94+(Spielmodus=4)*16)-(550,Spielmodus#32+ 
120+X2) ,3,b p 

END IF 

X=Spielmodus 

WEND 

IF Spielmodus=-2 THEN Copyright 

IF Spielmodus=3 THEN Highscores.ansehen 

IF Spielmodus=4 THEN SYSTEM 

GOSUB Text.loeschen 


' **#* Auswahl der Spieloberfläche zu 


LOCATE 12,9 :.Hilf=MOUSE(0) 

Prnt “Bitte wählen Sie die Spieloberfläche, indem Sie sie anklicken” 
Bildauswahl: 

LOCATE 14,20 : Prnt "Name des Bildes Größe” 

LOCATE 16,20 : Prnt ”- Standard 1 4x4" 

LOCATE 18,20 : Prnt ”- Standard 2 жр 

LOCATE 20,20 : Prnt ”- Megabild 6x8” 

LOCATE 22,20 : Prnt ”- Elefant 4x4" 

LOCATE 24,20 : Prnt ”- Auto (Auburn Speedster) 4 x 4” 

LOCATE 26,20 : Prnt ”- Klassik (römische Zahlen) 6 x 5” 


WHILE MOUSE(0)<1 OR В114<0 OR Bild>6 
Bild=INT( (PEEKW(WINDOW(7)+12) 4128) /16) 
IF Bild<>X AND X>-1 AND X<6 THEN 
LINE (148,X*164118) -(422,X*164128) ,2,b 
END IF 
IF Bild>-1 AND Bild« 6 THEN 
LINE (148,B114*16+118)-(422,Bi1d*16+128) ,3,b 
END IF 
X-Bild 
WEND 
GOSUB Text.loeschen 


RESTORE ` 

FOR 1=0 TO Bild 
READ Bild$ 
READ Hoehe 
READ Breite 


'Name des Bilds im Verzeichnis Bilder 
'Anzahl der Felder in Y-Richtung 
"Anzahl der Felder in X-Richtung 
READ XPixel 'Pixelbreite der Felder 
READ Start 'X-Startkoordinate 
READ Vertausch ‘Anzahl der Vertauschungen 
READ XMovanz "Anzahl der Schritte fuer Softscroll 
READ Xmove 'Pixelanzahl fuer Softscroll 
NEXT I 


IF Spielmodus=3 THEN RETURN 
Spieler=1 


" *** Bilderdaten ЖЖ 

DATA Standard , 4, 72, 110, 400, 
DATA Standard II, 5, 56, 125, 500, 
DATA Megabild , 6, 36, 146, 1000, 
DATA Elefant m^ 72, 110, 500, 
DATA Auto ,% 72, 110, 500, 
DATA Klassik sh, 48, 134, 500, 


' жж Ermittlung der Vorgabezeit in Zeitspielmodus *** 


IF Spielmodus=1 THEN 

OPEN "R^,1, ":Highscore/"4Bild$4".Zeit",27 

FIELD #1,20 AS Spieler$,2 AS Versch$,5 AS Zeit$ 

Hilf-MOUSE(0) 

LOCATE 12,20 : Prnt "Welche Vorgabezeit wollen sie schlagen ???" 

LOCATE 14,25 : Prnt "2 Minuten (nur für Profis)" 

LOCATE 16,25 : Prnt "5 Minuten (erfahrene Spieler)" 

LOCATE 18,25 : Prnt "10 Minuten (totaler Anfünger)" 

LOCATE 20,16 : Prnt "Highscore (Kampf gegen den Besten aus dem 
Highscore)” 

LOCATE 22,16 : Prnt STRING$(17, "-")+">ZEIT-HIGHSCORES< "«STRING$ 

(18, "-^) 

Y=22 : GOSUB Highscore.Liste 


WHILE MOUSE(0)«1 OR Vorg.Zeit«0 OR Vorg.Zeit>4 
Vorg.Zeit-INT((PEEKW(WINDOW(7) 412) -112) /16) 

IF Vorg.Zeit« >X AND X>-1 AND X<4 THEN 

LINE (118-(X« 3) *72, 4164102) -(5424112*(X« 3) 34164112) ,2,b 


END IF 
IF Vorg.Zeit>-1 AND Vorg.Zeit<4 THEN ч 
LINE (118-(Vorg.Zeit<3)*72,Vorg.Zeit*16+102)-(542+112%(Vorg.Zeit 
« 3), Vorg.Zeit*16«112),3,b 
END IF 
X=Vorg.Zeit 
WEND 
GOSUB Text.loeschen 


Vorg.Zeit=-((Vorg.Zeit=0)*120+(Vorg.Zeit=1)*300+(Vorg.Zeit=2)*600) 
IF Vorg.Zeit=0 THEN Vorg.Zeit=VAL(LEFT$(Zeit$,2))*60+VAL(RICHT$ 
(Zeit$,2)) 

CLOSE 

END IF 


' *** laden des Bilds und durchfuehren der Vertauschungen Жж 
FOR 12255 TO 1 STEP -1 
LINE (1,1)-(640,256-1),0 
NEXT I % 
FOR 120 TO 640 
LINE (1,0)-(640-1,256),0 
NEXT I 


Spielbeginn: 


"Lade.Bild "Bilder/”+Bild$,Lesefehler$ 


IF Lesefehler$ <> ”” THEN Fehler.in.Bilddatei 


LOCATE 1,30 : TIMER OFF 
IF Spielmodus=0 THEN * 
Prnt " --- Normales Spiel ---” 
Zeit=0 : ON TIMER(1) GOSUB Zeitzaehler.auf 
ELSEIF Spielmodus-1 THEN 
Prnt "--- Spiel gegen die Zeit ---" 
Zeit=Vorg.Zeit : ON TIMER(1) GOSUB Zeitzaehler.ab 
ELSEIF Spieler=1 THEN 
Prnt "Spieler 1: Zeit vorgeben...” 
Zeit=0 : ON TIMER(1) GOSUB Zeitzaehler.auf 
ELSE 
Prnt "Spieler 2: Zeit unterbieten" 
ON TIMER(1) GOSUB Zeitzaehler.ab 
Vorg.Zeit=Zeit+1 
END IF 
Min=INT(Zeit/60) : Sek=Zeit MOD 60 
LOCATE 3,30 : Prnt "Anzahl der Bewegungen: 0” 
LOCATE 5,30 : Prnt “Zeit: ’+STR$(Min)+” Minuten”+STR$(Sek)+” 
Sekunden ^ Р 
Zaehler=0 
FOR I=1 TO Hoehe 
FOR T=1 TO Breite 
Zaehler=Zaehler+1 
Wert(T,I)=Zaehler 
NEXT Т 
NEXT I 


X=Breite : YsHoehe ' Koordinaten des Leerfelds 
юж Routine zum Vertauschen der Felder ЖЖ 


FOR I-1 TO Vertausch 


Zufall=INT(RND*4)+1 


IF Zufalls1 AND Y>1 THEN 
SWAP Wert(X,Y),Wert(X,Y-1) : Y=Y-1 
SCROLL (X*XPixel+Start, Y*20+44) ~ 
((X+1) *XPixel+Start-1,Y*20+83) ,0,20 


ELSEIF Zufall=2 AND Y<Hoehe THEN 
SWAP Wert(X,Y) Wert(X,Y«1) : Y=¥+1 
SCROLL (X*XPixel«Start,YX20424)- 

((X+1)*XPixel+Start-1, Y*20+63) ,0,-20 


ELSEIF Zufall=3 AND X>1 THEN 
SWAP Wert(X,Y) ‚Wert(X-1,Y) : X=X-1 
SCROLL (X*XPixel+Start, Y*20+44)- 
((X42) XXPixel«Start-1,Y*20463) ‚XPixel,0 


ELSEIF Zufall=4 AND X« Breite THEN 
SWAP Wert(X,Y) ,Wert(X+1,Y) : Х=Х+1 
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SCROLL ((X-1)*XPixel+Start, Y%20+44)-((X+1)*XPixel+Start-1, 
Ү%20-62),-ХРіхе1,0 
END IF 


NEXT I 
' жжж Spielroutine, bewegen der Felder durch Mausklick ` mx 


Ү-0 ' Anzahl der Bewegungen 
Zeitaus=0 


GET (250,80)-(450,120) ,2Feld 

LINE (258,88)-(450,120),1,bf 

LINE (250,80)-(442,112),0,bf 

LINE (250,80)-(442,112),1,b 

LOCATE 12,34 : Prnt "---» Spielbeginn <---” 
LOCATE 13,34 : Prnt "Start mit Mausklick" 
GOSUB Warte.auf.Maus 

LINE (250,80)-(450,120),0,bf 

PUT (250,80),ZFeld 

TIMER ON 


Bewege. Felder: 


WHILE MOUSE(0) <1 

IF Zeitaus THEN Spiel.beendet 

LOCATE 5,30 : Prnt "Zeit: ”+STR$(Min)+” Minuten”+STR$(Sek)+” 
Sekunden ^ 

WEND - 


X2=X*XPixel+Start : Y2-Y*20444 
X3-MOUSE(1) : Y3=MOUSE(2) 
Fertig=1 : Zaehler=0 


IF X3>500 THEN 
IF Y3>65 AND Y3« 90 THEN Hauptmenue.eins 
IF Y32 100 AND Y3< 120 THEN 
TIMER STOP 
GET (250,80)-(450,120),ZFeld 
LINE (258,88)-(450,120),1,bf 
LINE (250,80)-(442,112),0, bf 
LINE. (250,80)-(442,112) ,1,b 
LOCATE 12,34 : Prnt "  ---» Pause <---” 
LOCATE 13,34 : Prnt "Weiter mit Mausklick" 
GOSUB Warte.auf.Maus 
LINE (250,80)-(450,120) ,0,bf 
PUT (250,80),ZFeld 
TIMER ON 
GOTO Bewege.Felder 
END IF 
END IF 


IF X3>X2 AND X3<X2+XPixel THEN XRichtung-0 ELSE XRichtung- 
SGN(X3-X2) 
IF Y3>Y2 AND Y3<Y2-30 THEN YRichtung-0 ELSE YRichtung=SCN(Y3-Y2) 


IF XRichtung-1 AND YRichtung=1 AND X<Breite THEN . 

SWAP Wert (X,Y) ,Wert(X+1,Y) : Х=Х+1 : V=V+1 

FOR I=1 TO XMovanz 
SCROLL ((X-1)*XPixel+Start, ¥#20+44)-((X+1) *XPixel+Start-1, 
¥*20+63),-Xmove ,0 

NEXT I 


ELSEIF XRichtung=0 AND YRichtung=-1 AND Y>1 THEN 
SWAP Wert(X,Y),Wert(X,Y-1) : YeY-1 : V=V+1 
FOR I=1 70 20 STEP 2 


SCROLL (X*XPixel«Start,Y*20444)-((X«1)*XPixel«Start-1,Y*20483),0,2 


NEXT I 


ELSEIF XRichtung=0 AND YRichtung=1 AND Y<Hoehe THEN 
SWAP Wert(X,Y) ‚Wert(X,Y+1) : Y=Y+1 : V=V+1 
FOR I=1 TO 20 STEP 2 


SCROLL (X*XPixel+Start, Y*20+24)-((X+1)*XPixel+Start-1,1%20+63) ,0,-2 


NEXT I 


ELSEIF XRichtung=-1 AND YRichtung=1 AND Х>1 THEN 
SWAP Wert(X,Y)Wert(X-1,Y) : XeX-1 : V=V+1 

FOR I=1 TO XMovanz 

SCROLL (X*XPixel+Start, Y%20+44)- 
((X+2)*XPixel+Start-1,Y*20+63) ,Хпоуе,0 

NEXT I 
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| SPIELE 


END IF 


FOR I=1 TO Hoehe 
FOR XT=1 TO Breite 
Zaehler=Zaehler+1 
IF Wert(XT,I)<>Zaehler THEN I=Hoehe : XT=Breite : Fertig=0 
NEXT XT 
NEXT I 


LOCATE 3,54 : Prnt STR$(V) 
IF Fertig=1 THEN TIMER STOP : GOTO Spiel.beendet 


GOTO Bewege. Felder 
"жж Alle Felder richtig... Statistik und Highscore #** 
Spiel.beendet: 


Lade.Bild "Bilder/HAUPTMENÜ”,Lesefehler$ 

IF Lesefehler$ <> ”” THEN Fehler.in.Bilddatei 
Ladezahl=Ladezahl+1 
Pufferinhalt&=xRead&(FileHilf&,Ein.Puffer&, IcLaen&) 
Tiefe%=PEEK(Ein.Puffer&+8) 


Ben.Speicher&=20480% (Tiefe%+1)+5000 
IF FRE(-1) <Ben.Speicher& THEN Lesefehler$="Zuwenig Speicher": 
GOTO Raeum.auf 


SCREEN 2,640,256, Tiefet,2 
WINDOW 2, “Schiebespielchen”, ,0,2 
Fenster.Flag(67684&) 


SSCREEN& =PEEKL(WINDOW(7)+46) 
VPortk  =sSCREEN&+44 
sBitMapk =PEEKL(sSCREEN&+88) 
ScrnTiefe%=PEEK(sBitMap&+5) 
Farbzahl% =2'ScrnTiefe% 


FOR Schleife=0 TO ScrnTiefe% - 1 
Bitplane&(Schleife)=PEEKL(sBitMap&+8+(Schleife*4)) 
NEXT 


CALL LoadRGB4&(VPort&, Tab.C&,Farbzahl%) 


ELSEIF Ein.Text$="CMAP” THEN 
Ladezahl=Ladezahl+1 
Pufferinhalt&=xRead&(FileHilf&,Puffer.C&, IcLaen&) 


FOR Schleife=0 TO Farbzahl% - 1 
rot%=PEEK(Puffer.C&+(Schleife*3) ) 
gru%=PEEK(Puffer.C&+(Schleife*3)+1) 
bla%=PEEK (Puffer.C&+(Schleife%3)+2) 
POKEW(Tab.C&+(2*Schleife)), (rot#*16)+(gru%)+(bla%/16) 
NEXT 


ELSEIF Ein. Text$="CAMG” OR Ein. Text$=“CCRT” THEN 
Ladezahl=Ladezahl+1 
Pufferinhalt&=xRead&(FileHilf&,Ein.Puffer&, IcLaen&) 


ELSEIF Ein.Text$="ABIT” THEN 
Ladezahl-Ladezahl+1 
FOR P=0 TO Tiefef-i 
Pufferinhalt&exRead&(FileHilf&,Bitplane&(P),20480) 
NEXT 


ELSE 
FOR Schleife=1 TO IcLaen& 
PufferinhaltkexRead&(FileHilf&,Ein.Puffer&,1) 
NEXT 
IF (IcLaen& OR 1)=IcLaen& THEN 
Pufferinhalt&=xRead&(FileHilf&,Ein.Puffer&,1) 
END IF 


END IF 


IF Ladezahl=5 THEN GOTO Laden.erfolgreich 

IF Pufferinhalt&>0 THEN GOTO Lese.Schleife 

IF Pufferinhalt&« 0 THEN Lesefehler$-"Lesefehler." : GOTO Raeum.auf 
IF Ladezahl« 5 THEN Lesefehler$-"Datei kaputt..." : GOTO Raeum.auf 


Listing 1. (Fortsetzung) 


i SPIELE 


Laden.erfolgreich: 
Lesefehler$="" 
CALL LoadRGB4&(VPort&,Tab.C&, Farbzahl%) 


Raeum.auf: 
IF FileHilf& <> 0 THEN CALL xClose&(FileHilf&) 
IF Eig.Puffer& <> 0 THEN CALL FreeMem&(Eig.Puffer&,Mein.Puffer&) 


END SUB 


SUB Fenster.Flag(flag&) STATIC !” setzt Flags fÜr das Fenster 
wi&=WINDOW(7) 

POKEL (wi&+24),PEEKL(wi&+24) KOR flag& 

CALL RefreshWindowFrame (wi&) 

END SUB 


SUB Prnt(A$) STATIC ' schnellere Textausgabe als mit PRINT 
CALL Text(WINDOW(8) ,SADD(A$) , LEN(A$) ) 

PRINT 

END SUB 


SUB Alarm(anz£,T$(),HeightZ) STATIC 
anz%=anz%-1 : type%=0 ` A1$-"" 
FOR 1%-0 TO anz% 

Ү%(1%)-1%%12%15 
Х%-320-4%1ЕМ(79(1%)) 
A1$=A1$+MKI$ (XR) «CHR$ (YE (13) ) T$ (1%) «CHR8(0) 
IF I%<ang% THEN A1$=A1$+CHR$(1) ELSE A1$=A1$+CHR$(0) 
NEXT I$ 
CALL DisplayAlert(type%,SADD(A1$) ,Height%) 
END SUB 


! erzeugt Guru-Screen 


Schreibschutzfehler: 'wenn Diskette nicht Write-Enabled ist 
Mess$(0)="Fehler aufgetreten...” 

Mess$(1)="Die Diskette muß Write-enabled (Schreibschutz auf) sein,” 
Mess$(2)="da der Highscore gespeichert wird 111” 

Alarm 3,Mess$(),50 

CLOSE 

RESUME Anfang 


Fenler.in.Bilddatei: 'wenn Fehler beim Lesen einer Bilddatei auftrat 
Mess$(0)="Fehler aufgetreten..." 

Mess$(1)="So eine verdammte Sch.... 111” 

Mess$(2)-"Fehler bei: “+Bild$+” - Fehler: "«Lesefehler$ 

Alarm 3,Mess$(),50 

WINDOW CLOSE 2 : SCREEN CLOSE 2 

GOTO Hauptmenue.eins 


Copyright: 

GOSUB Text.loeschen 
LOCATE 12,13 : Prnt 
Anleitung <- sg 
LOCATE 14,13 : Prnt "Schiebespielchen wurde im Zeitraum vom 
10.4.-24.4.89" 

LOCATE 15,13 : Prnt "geschrieben und danach ständig verbessert..." 
LOCATE 17,13 : Prnt "Das Spiel selbst ist ganz einfach:" 

LOCATE 19,15 : Prnt "Die Felder müssen ganz einfach in ihre richtige" 
LOCATE 20,15 : Prnt "Reihenfolge gebracht werden." 

LOCATE 21,15 : Prnt "Die Taktik ist auch ganz einfach: immer streng" 
LOCATE 22,15 : Prnt "der Reihe nach die Felder sortieren." 

LOCATE 23,15 : Prnt " 

Der Highscore wird übrigens abgespeichert !!!" 

LOCATE 24,15 : Prnt "...und reus gehts mit «Ctrl» - C..." 

LOCATE 26,50 : Prnt "Thats all folks..." 

GOSUB Warte.auf.Maus 

GOSUB Text.loeschen 

GOTO Hauptmenue 


> Schiebespielchen- 


' Schiebespiel Ende 


Listing 1. (Schluß) 


' Schiebespiel Highscore-Creator 1989 G.Kensche 
' letzte Änderung: 27.5.89 


PRINT “Highscore-Creator 1989 by Guido Kensche”+CHR$(13) 
PRINT “Richtet den Highscore fuer das Schiebespiel ein" 


PRINT "oder loescht ihn. Auf der Diskette muß sich das” 
PRINT "Verzeichnis Highscore befinden !!!" 

PRINT "Die .info-Dateien koennen gelöscht werden” 
PRINT "(im Cli: cd Highscore , delete #?.info” 

PRINT CHR$(13); "Starten mit beliebiger Taste” 

WHILE INKEY$-"" : WEND 


FOR X=1 TO 6 
READ Hilf$ 
FOR Т-1 TO 2 
OPEN "R^,1, ":Highscore/"4Hilf$,27 
FIELD #1,20 AS Nam$,2 AS Versch$,5 AS Zeit$ 


FOR I=1 TO 5 

LSET Nam$="The Famous Guy” 
LSET Versch$-MKI$(3000) 
LSET Zeit$-"59:59" 

PUT #1,1 

NEXT I 


Hilf$-Hilf$«".Zeit" 
CLOSE 
NEXT T 
NEXT X 
END 


DATA Standard,Standard II,Megabild,Elefant,Auto,Klassik 


Listing 2. »HIGHSCORE-ERSTELLEN«, 
generiert die notwendigen Files im - 
Directory »HIGHSCORE«. Das Directory 
müssen Sie selbst anlegen. 


Höhen-Patch fr AmigaBasic 
passt die Höhe des Output-Windows 
an die verfgbare PAL-Höhe an 


erstmals veróffentlicht in 
AMIGA-Sonderheft 1 / Seite 137 und 138 


Patches von Peter Pórner und Alexander Wagner 
Programm von Peter Pérner 
aufgewärmt fr SCHIEBESPIELCHEN von Hans Waldhäusel 


wenn möglich, die Konvertierung im RAM ablaufen lassen 
(das Programm ist darauf ausgelegt !) 

zuerst das Original unter > >OldAmigaBasic<< in die 
RAM-Disk kopieren, dann Programm starten ! 


CLEAR, 50000& 
NeueHoehe$=CHR$(1)+CHR$(0) 'erste 1-256 


OPEN”ram:OldAmigaBasic” FOR INPUT AS #1 LEN=4096 
OPEN"ram:NewAmigaBasic" FOR OUTPUT AS #2 LEN=4096 


PRINT #2, INPUT$(&H57EC, #1); "Anfang kopieren 
PRINT #2, NeueHoehe$; 'neue Höhe 
a$=INPUT$(2, #1) "alte Höhe ignorieren 


PRINT #2, INPUT$(&H7000, #1); 'Rest kopieren 
PRINT #2,INPUT$(&H7000, #1); 

PRINT #2,INPUT$(&H5C00, #1); 

WHILE NOT EOF(1) 

PRINT #2,INPUT$(1, #1); 

WEND 

CLOSE #1, #2 


END 


Listing 3. Mit »HöhenPatch« steht Ihnen 
die volle PAL-Auflösung in Amiga-Basic 
zur Verfügung 
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Grafische Meisterleistung: Memory 


SPIELE 


Zwilling gesucht 


ш ЫШ БИЕ 
et pete БЕ ЕЗ ЕЛ ШЇ 
el ЕЕ EE) 


Sie meinen, 

Sie haben ein gutes 
Gedachtnis? 

Na mal sehen... 


Von Hans Waldhäusel 


artenspiele auf dem 
Amiga haben Tradition. 
Poker (meist mit dem 


Zusatz »Strip«), Patiencen, Bac- 
cara, Black Jack und so man- 
ches andere Spiel gibt es in 
mehreren Varianten. Wir pra- 
sentieren einen weiteren Ver- 
treter dieses Genres: Memory. 

Memory in der Version 2.0 ist 
in Assembler geschrieben, wird 
mit der Maus gesteuert und bie- 
tet in Anbetracht der Kürze des 
ausführbaren Programms (nur 
etwas mehr als 8 KByte) er- 
staunlich viel Spielspaß. Die 
Spielregeln von Memory zu er- 
klären, hieße wahrscheinlich, 
Bier nach München zu tragen 
(oder die sprichwörtlichen Eu- 
len nach Athen). Aber weil 
»wahrscheinlich« nicht »sicher« 
ist, finden Sie hier eine kurze 
Einführung. 

Zuerst zum Vorbild: Ein Paket 
Karten, in dem jedes Bild zwei- 
mal vorkommt, wird gut durch- 
gemischt und die Karten wer- 
den mit der Bildseite nach un- 
ten auf den Spieltisch gelegt. 
Es ist Aufgabe des Spielers, die 
Kartenpárchen herauszufinden 
und aus dem Spiel zu nehmen. 
Dazu deckt der Spieler eine der 
Karten auf und wáhlt eine zwei- 
te aus den noch verdeckten 
Karten, von der er weiB (oder 
glaubt, zu wissen), daß sie der 
gesuchte Zwilling ist. War die 
Wahl richtig, so ist das Párchen 
aus dem Spiel zu nehmen und 
dem Spieler ein Punkt gutzu- 
schreiben. Wenn nicht, werden 
beide Karten wieder umge- 
dreht. Das Gehirntraining be- 
steht nun darin, sich die bei je- 
dem Fehlversuch gesehenen 
Karten zu merken und dieses 
Wissen bei náchster Gelegen- 
heit nutzbringend anzuwen- 
den. Nehmen mehrere Perso- 
nen am Spiel teil, kommt nach 
jedem Fehlversuch der nách- 
ste an die Reihe. Ziel des Spie- 
les ist, alle Párchen mit móg- 
lichst wenig Fehlversuchen ein- 
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MEMORY 
4 1 SPIELER 

2 SPIELER 

3 SPIELEN 


KARTEN 


Ы о SEIT 
ы 2 6 ЫБ 
sius. 


SPIELER ` 
PAARE. ` 


ZUG NR. : 
Boe 


Bild 1. Auf der Suche nach dem Zwilling 


ander zuzuordnen. Spielt man 
allein, so zählt die Anzahl der 
Versuche; bei mehreren Spie- 
lern zählt die Anzahl der »er- 
beuteten« Pärchen und damit 
die Anzahl der Punkte. 

Bei der AMIGA-Implementa- 
lion laden Sie zuerst die Work- 
bench und dann Memory durch 
Anklicken des Icons. Ein Start 


MEMORY ABOUT 


- START 
- HI-SCORE 
- QUIT 


- IFF-LADEN 
- IFF-SAVEN 


aus dem CLI ist nicht vorgese- 
hen. Nach dem Laden (die 8K 
sind schnell im Speicher) zeigt 
Ihnen Memory kurz die aktuel- 
len Kartenbilder, was aber keine 
Rückschlüsse auf die Lage der 
Karten im Spielfeld zuläßt, da 
der Mischvorgang auf Zufalls- 
zahlen basiert. 

Zu Spielbeginn befinden Sie 
sich immer іт Ein-Spieler- 


Modus und es wird immer die 
erste Karten-Datei geladen (Er- 
läuterungen hierzu finden Sie 
bei der Erklärung der Menü- 
punkte). Nach bewährter 
AMIGA-Manier steht Ihnen jetzt 
durch Druck auf die rechte 
Maustaste eine Menüleiste mit 
folgenden Funktionen zur Ver- 
fügung: 


hier hat sich der 
Programmautor Andreas 
Herckner verewigt 
(Neu)start des Programms 
die Besten-Liste (Top-Ten) 
Programm beenden, zu- 
rück zur Workbench 
Spielmodus für 1 bis 4 
Mitspieler anwählen 

neue Karten und Restart 
Leerbild-Raster auf 
beliebige Diskette 
speichern 


Einige der Menüpunkte be- 
dürfen einer näheren Erläute- 
rung. Beginnen wir mit der An- 
zahl der Mitspieler. Wie beim 
realen Kartenspiel ist im Mehr- 
Spieler-Modus nach jeder Fehl- 
wahl der Nächste an der Reihe. 
Welcher Spieler am Zug ist, 
wird durch den Mauszeiger si- 
gnalisiert, der immer die Kenn- 
zahl des aktiven Spielers zeigt. 


a, HI. 


: 999 


Im unteren Bildschirm-Bereich 
werden sowohl die Anzahl der 
je Mitspieler gefundenen Pär- 
chen als auch die Gesamtzahl 
der Versuche mitprotokolliert. 
Eine Änderung der Spielerzahl 
führt automatisch zu einem 
Neustart des Programmes. 

Die Wahl von »START« löscht 
alle bis dahin aufgezeichneten 
Werte, also Zugzahl und Pär- 
chen je Spieler. Auch die Karten 
werden neu. gemischt, doch 
bleibt die zu Beginn geladene 
Karten-Datei aktiv. 

Der Menüpunkt »IFF-LA- 
DEN« holt für Sie ein neues 
Karten-Paket aus der Schubla- 
de. Durch die Auslagerung der 
Daten in IFF-Files stehen Ihnen 
unbegrenzt viele verschiedene 
Spielflächen zur Verfügung 
(»unbegrenzt« ist natürlich ab- 
hängig von der Größe Ihres 
Massenspeichers, aber wenn 
Sie eine 80-MB-Hard-Disk mit 
MEMORY-Karten füllen wollen 
- bitte sehr). Der bei der Wahl 
von »IFF-LADEN« eingeblende- 
te Requester erlaubt vollen Zu- 
griff auf jedes Speichermedium. 
MEMORY gibt zwar beim er- 
sten Aufruf dieser Funktion den 
Namen »MEMO__PIC« vor, doch 
sind Ihrer Fantasie bei der Na- 
mensgebung keine Grenzen 
gesetzt. 


97 


Mit »IFF-SAVEN« kommen 
wir zum künstlerischen Teil des 
Abends. Mit dieser Leerbild- 
Vorlage und einem Malpro- 
gramm zeichnen Sie Ihre eige- 
nen MEMORY-Karten. Einzige 
Bedingung: Med-Res-Format, 
also 640 x 200 Punkte Auflö- 
sung. Die ersten vier Farben 
sind festgelegt, der Rest bleibt 
Ihrem Geschmack überlassen. 
Angenommen, Sie sind stolzer 
Besitzer eines Originals von 
»Deluxe Paint« (als Besitzer ei- 
ner Raubkopie hätten Sie kei- 
nen Grund, stolz zu sein). Sie 
laden und starten »MEMORY« 
wie beschrieben und wählen 
den Menü-Punkt »IFF-SAVEN«. 
In den eingeblendeten Reque- 
ster tragen Sie Pfad- und File- 
namen für Ihr MEMORY-Leer- 
bild ein, also z.B. 


df1:Pictures/Med-Res/ 
memory.pic 


Beenden Sie »MEMORY« 
und starten Sie »Deluxe Paint«. 
Am besten wählen Sie gleich 
von Beginn an die Med-Res- 
Auflösung. Laden Sie das File 
»memory.pic« und schützen Sie 
es vor versehentlichem Über- 
schreiben, indem Sie aus dem 
»Effects«-Menü den Punkt 
»Background-Fix« wählen. Nun 
können Sie entweder wild 
drauflos malen oder beispiels- 
weise Brushes laden und auf 
das Rastermaß von »MEMO- 
RY« verkleinern - verwenden 
Sie zum Verkleinern die Taste 
<h>;.das ist viel bequemer als 
dauernd die Menü-Leiste auf- 
und abzufahren. Der Raster 
von »memory.pic« ist übrigens 
nur eine GróBen-Indikation. Sie 
kónnen diesen Raster unbe- 


sorgt übermalen - »MEMORY« 
holt sich seine Spielkarten 
schon im richtigen Format. 
Aber hüten Sie sich, zwei glei- 
che Karten herzustellen - Sie 
machen sich nur selbst das 
»MEMORY«-Leben schwer. 
Und noch ein Tip: Besonders 
edel wirkt das Ganze, wenn Sie 
zum Schluß den Rahmen der 
Spielkarte mit der Hintergrund- 
farbe ausfüllen. Haben Sie alle 
Kästchen gefüllt, speichern Sie 


es unter einem beliebigen Ма- 


men; wie gesagt, »MEMORY« 
läßt Ihnen da völlig freie Hand. 
Wollen Sie Ihr Kunstwerk je- 
doch als Default-File deklarie- 
ren, damit es bei Programm- 
Start automatisch nachgeladen 
wird, müssen Sie es unter dem 
File-Namen »MEMO__PIC« im 
selben Directory wie »MEMO- 
RY« ablegen. 

Genug des  Vergnügens, 
kommen wir zur Arbeit. Als stol- 
zer Besitzer der Leserservice- 
Diskette gehören Sie zu jenen 
Glücklichen, die Ihre gequälten 
Fingerspitzen nicht in Geschirr- 
spülmittel zu baden brauchen. 
Sie kopieren einfach die in der 
Schublade »MEMORY« abge- 
legten Files »MEMORY-Hl«, 
»MEMORY-VERS 2.0« und 
»MEMO__PIC« mit 


copy dfx:memory/#? 
to dfy: all 


auf Ihre Spiele-Diskette (am be- 
sten in ein eigenes Directory 
oder noch besser auf eine ME- 
MORY-Diskette wegen des de- 
aktivierten Schreibschutzes). 
»x« und »y« stehen für die zur 
Verfügung stehenden Laufwer- 
ke, wobei Sie anstelle von »dfy:« 


jXPOHOOOOOOHOHOOOOOOOOOOHOHOHOOOHOOHOOOHOORHOHO HOOK 


же 
peek Vers. 
ж 
Ғы >>>* Data * 
Pee 


—lvoWait 
—lvoOpenLibrary 
_lvoCloseLibrary 
_lvoOpenWindow 
—lvoCloseWindow 
—lvoSetPointer 
—lvoClearPointer 
-lvoOpenSereen 
-lvoCloseSereen 
-lvoDrawImage 
—lvoPrintIText 


-$13e 
-$228 
-$19e 
-$cc 
-$48 
-$10e 
-$3c 
-$c6 
-$42 
-$72 
-$48 
-$15c 
-$c6 
-$126 
-$180 
-$174 
-$17a 
-$84 


—lvoAutoRequest 
_lvoDelay 
—lvoFindTask 
—lvoWaitPort 
-lvoGetMsg 
-lvoReplyMsg 
—lvoForbid 


Programm - Memory-Amiga by A. Herckner 
14 4 89-02.23 

Copyright by A. Herckner 

muß im ChipRam stehen< << 
Assembler - Profimat von Data Becker 

; JOGOOOOOOOOOOOUOOHOOOOUOOOOOOOOOOUOOOOOOHORRROOOOH (I| 


DI 
ж 
DI 
DI 
DI 


selbstverstándlich auch »ram:« 
einsetzen kónnen. Das wár's 
auch schon gewesen. 

Etwas schwerer haben es 
diejenigen, die den Source- 
Code abtippen wollen (oder 
müssen - die Inflation nagt am 
Taschengeld). Listing 1 enthált 
das Hauptprogramm »MEMO- 
RY-VERS 2.0«. Nachdem Sie 
mit Sysiphus im Geiste Bruder- 
schaft getrunken haben, kön- 
nen Sie Ihren Assembler an- 
werfen. Wichtig dabei ist nur, 
daß Sie im Assemblierungs- 
Auswahlmenü »DATA« auf 
»CHIP« setzen. Auf einen Ab- 
druck der Bilddaten haben wir - 
wie wir glauben in Ihrem Inter- 
esse - verzichtet. Das Leerbild- 
Raster wird vom Programm ge- 
neriert (siehe »IFF-BILD SA- 
VEN«), und malen ist sicher an- 
genehmer als rund 23000 By- 
tes einzutippen. Auch das 
Highscore-File »MEMORY-Hl« 
wird vom Programm automa- 
tisch angelegt, also wundern 
Sie sich bitte nicht, daß »nur« 
ein Listing einzugeben ist. Da 
Sie »MEMORY« aber nur von 
der Workbench aus aufrufen 


‘können, müssen Sie noch ein 


beliebiges TOOL-Icon von einer 
Ihrer Disketten für »MEMORY« 
ummodeln. Ein einfallsloses 
Beispiel: das DiskCopy-Icon 
von Ihrer Workbench. Rufen 
Sie das CLI auf und geben Sie 
ein: 
copy SYSTEM/Diskcopy. 
info ram:xyz.info 
сору ram:xyz.info "dfy: 
MEMORY-VERS 2.0.info” 

Es ist, wie wir meinen, an der 
Zeit, ein wenig auf die Technik 
des Programms einzugehen. 


-lvoPermit 
-lvoLoadROBA 
_lvoSetMenuStrip 
-lvoClearMenuStrip 
-lvoltemAddress 
—lvo0ffMenu 
—lvo0nMenu 
_lvo0pen 
-1уоС1ове 
-lvoWrite 
—lvoRead 
-lvoCurrentDir 
-lvoalloemem 
—lvofreemem 
-lvoloErr 
„lvoActivateGadget 
-lvoAddGadget 
_ЛуоВеМоуебайве+ 
-lvoOnGadget 
-lvoRequest 
-lvoEndRequest 
—lvoClearScreen 
—lvoMOVE 
—lvoExit 


Pr.Cli 
Pr_MsgPort 


Für die Assembler-Spezialisten 
unter Ihnen ist der sehr ausführ- 
lich kommentierte Source-Code 
wohl informativ genug. Für die 
weniger beschlagenen Leser 
(und Spieler) hier einige An- 
merkungen: 

MEMORY ist voll multitask- 
ing-fähig, was man so man- 
chem berufsmäßigen Spiele- 
Programmierer ins Stammbuch 
schreiben sollte. Verwerflichkei- 
ten wie Polling am Nachrichten- 
Port und damit Zeitdiebstahl an 
anderen Tasks oder absolute 
Speicherzugriffe werden Sie 
hier im Gegensatz zu vielen 
kommerziellen Programmen 
(Gott sei Dank) vergeblich su- 
chen. Fehler werden korrekt ab- 
gefangen, Ressourcen sauber 
angefordert und nach Ge- 
brauch ebenso sauber wieder 
freigegeben. 


Tüftlerei 


Wáhrend das Programm auf 
eine Eingabe des Spielers war- 
tet, wird keine Rechenzeit ver- 
schwendet - der Programm- 
Task wird in den Status »Wait« 
versetzt und wartet auf ein klas- 
sifiziertes Ereignis am Nach- 
richten-Port (in diesem Fall eine 
der beiden Maustasten). Sehen 
Sie sich den Programmteil zwi- 
schen den Labels »loop« und 
»MsgOff« in aller Ruhe an. Wie 
uns Andreas Herckner mitteilte, 
ist MEMORY sein erstes Pro- 
gramm - freuen wir uns schon 
mal auf das náchste. so 


Hans Waldhäusel kam als Programmierer vom 
128er zum Amiga. Sie erreichen ihn über unse- 
re Verlagsanschrift (Markt&Technik Verlag 
AG, Redaktion Sonderhefte, z.Hd. Herrn 
Waldhäusel, Hans-Pinsel-Str. 2, 8013 Haar). 
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Callsys:Macro $\1 
JSR _1vo\1(A6) 
Endm 


Linksys:Maero $\1,$\2 
MOVE.L A6,-(SP) 
MOVE.L \2,A6 
JSR _LVO\1(A6) 
MOVE.L (SP)+,A6 
Endm 


MOVE.L SP,Initial SP ;Stapel Zeiger sichern 
MOVE.L 4,46 ;Zeiger ExecBase laden 
MOVE #0,А1 30 = eigener Task 
Callsys FindTask jAdresse suchen 
MOVE.L DO,A4 
TST.L PR CLI(A4) jlaufen wir unter WB? 
BNE Exit ;Nein dann **exit clix* 
LEA PR MsgPort(A4) ‚AO 
Callsys WaitPort jWarte auf Start Zeichen 
LEA PR MsgPort(A4) ‚AO 
Callsys GetMsg iStartCode holen 
MOVE.L DO,WBenchMsg ;Sichern zum AbMelden 
LEA Intui,A1 
MOVEQ #0,D0 
Callsys OpenLibrary ;Librarys öffnen 
MOVE.L DO,IntuitionBase р ^" -Ваве sichern 
BEQ _ Fehler 
LEA Dos, AL 
MOVEQ #0,D0 
Callsys OpenLibrary 
MOVE.L DO,DosBase 

Fehleri 

Gfx, AL 

#0,D0 
Callsys OpenLibrary 
MOVE.L DO,GfxBase 
BEQ Fehler2 
LEA Screen, A0 ;ScreenStruktur-Zeiger 
Linksys OpenScreen,IntuitionBase ;Screen öffnen 
MOVE.L DO,ScreenBase jSereenadresse sichern 
BEQ Fehler3 
BSR Finit 
LEA Window, AO ;FensterStruktur-Zeiger 
Linksys OpenWindow,IntuitionBase ;Fenster öffnen 
MOVE.L DO, WindowBase jFensterStruk.Adr.sichern 
BEQ Fehler4 
MOVE.L . #30150,D0 2 
MOVE.L %%10002,01 ;ChipSpeicher für Bilder 
Callsys AllocMem 
MOVE.L D0,I2 
ADDI.W %192,00 
MOVE.L DO,ImagePici 
CMP.L #192,р0 
BNE ProgStart ;alles I/O dann weiter 
MOVE.L #FehlerText, FT ;sonst alles beenden 
BSR Printi 
BSR Wait 
BRA 1оор11 


Loopi: MOVE.L OldDir,Di 3EndeProg 
Linksys CurrentDir,DosBase alles beenden 
Loopii: MOVE.L 12,A1 
MOVE.L #30150,DO 
Callsys FreeMem 
MOVE.L WindowBáse,A0 
Linksys ClearMenuStrip,IntuitionBase 
MOVE.L WindowBase,A0 
Linksys ClearPointer,IntuitionBase 
MOVE.L WindowBase,A0 
Linksys CloseWindow, IntuitionBase 
Fehler4: MOVE.L ScreenBase,AO 
Linksys CloseScreen, IntuitionBase 
Fehler3: MOVE.L GfxBase,A1 
Callsys CloseLibrary 
Fehler2: MOVE.L розђазе,А1 
Callsys CloseLibrary 
Fehleri: MOVE.L IntuitionBase,A1 
Callsys CloseLibrary 
Fehler: TST.L WBenchMsg ;gibs MSG 
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SPIELE 


BEQ Exit ;Nein dann war's CLI 

Callsys Forbid 

MOVE.L WBenchMsg,A1 

Callsys ReplyMsg ;TASK abmelden 
Exit: MOVEQ #0,00 ;ReturnCode 

MOVEQ #0,D1 

MOVE.L Initial SP,SP jalter StapelZeiger 

RTS jAUFWIEDERSEHEN 


jGOOOOOOOHOOHOOOHOHOOOHOHOOOOOOOOOHOHOOHHOHOOHOHOOO|O]K 


ProgStart: BSR SetMenu ;Menue aufbauen 
MOVE.L WindowBase,A0 
MOVE.L 50(A0),RastBase ;Rastport - Zeiger 
MOVE.L 86(A0),UserPort ;Userport - Zeiger 
LEA HiSpeicher, A0 
MOVE.L A0,HiZahlTab ;HiScore ZahlenTabelle ^ 
ADD.L #22,А0 
MOVE.L AO,HiTextTab ; "" TextZeigerTabelle ^ 
ADD.L #44,А0 
MOVE.L А0,Н1Тех%5ре 3 
MOVE.L WBenchMsg, A0 i 
MOVE.L $24(А0),АО jStart Look 
MOVE.L (A0),Di 
MOVE.L D1,CdDir 
Linksys CurrentDir,DosBase ;setzen 
MOVE.L DO,O1dDir ҒЫ 
MOVE.L #FileHI,D1 ; 
MOVE.L %1005,02 
Linksys Open,DosBase ;HiScore laden 
MOVE.L DO,FileHD 
BEQ ErrHi ;Fehler dann Hi Neu 
MOVE.L DO,D1 
MOVE.L #HiSpeicher,D2 
MOVE.L #566,D3 
LINKSYS Read,DosBase 
MOVE.L 00,-(5Р) 
MOVE.L HiTextTab,AO 
MOVE.L HiTextSpe,DO 
MOVEQ #9,D1 
Hiofl: ADD.L ро, (А0)+ ‚Offsets für Hi-Texte 
DBRA D1,Hiof1 ;zum Speicher addieren 
MOVE.L FileHD,D1 
Linksys Close,DosBase 
MOVE.L (SP)+,DO ; 
BPL EPA READfehler? 
ErrHi: BSR HiNeu ;Ja Neu 
EPA: BRA Iffread ;Ende Prog.Anfang 
Neu: LEA ImageTabelle,A1 ;Neues Spiel 
MOVEQ #1,D1 
MOVEQ #38,D0 
Karten: MOVE.B D1,39(A1) 
MOVE.B D1,(A1)+ ;SpielKartenTab.anlegen 
ADDQ #1,D1 
DBRA DO,Karten 
MOVE.B #0,Zeiger 
MOVE.B #39,PaarZähler 
LEA ImageTabelle,AO 
MOVE.L %1000,04 
NZiehen: MOVE.B $dff006,D0. 
AND.B  D4,DO 
ANDI.L #%1111111,D0 
CMPI.B #77,D0 
BHI NZiehen 
MOVE.B (A0,D0),Di 
Ziehen2: DBF D3,Ziehen2 ;Karten mischen 
MOVE.B $dff006,D3 
ROL.B #2,D3 
ANDI.L #%1111111,D3 
СМРІ.В. #77,D3 
BHI Ziehen2 
MOVE.B (A0,D3),D2 
MOVE.B D2,(A0,D0) 
MOVE.B D1,(A0,D3) 
DBF D4,NZiehen pe 


”” TexteSpeicher 


Listing 1. MEMORY - der Quell-Code wurde 
fiir den Data-Becker-Profimat geschrieben. 
Eine Konvertierung auf andere 

Assembler dürfte relativ einfach sein. 


#0,ZugNr 
#0,PaarZL 
#0,SpielerNr 
Pointer,Al 
SetSprite 
SpielBild 
Wait 
#$100,D6 
BEQ Loop3 
CMP # $68 ,D7 
BEQ MousePos 
BRA Loop 
Wait: MOVE.L UserPort,A0 
MOVE.B $f(A0),D1 
MOVEQ #0,D0 
BSET D1,D0 
Callsys Wait 
GMsg: MOVE.L UserPort,A0 
Callsys GetMsg 
TST.L DO 
BEQ Msgoff 
MOVE.L D0,A1 
MOVE.L $14(A1),D6 
MOVE $18(A1),D7 
Callsys ReplyMsg 
CMP.L #$40000,06 
BNE GMsg 
BSR SpielBildi 
MOVE.L %%40000,06 
BRA CMsg 
Msgoff: RTS 


MousePos: MOVEQ #0,D3 
MOVEQ #0,D4 
MOVE.L WindowBase,A0 
MOVE $0c(A0) ,D4 
MOVE | $0e(A0),D3 
MOVE D3,MousePosX 
MOVE ` D4,MousePosY 
CMP # 8,D3 
BLS Loop 
CMP # 632,03 
BGE Loop 
CMP # 24,D4 
BLS Loop 
СМР % 216,04 
ВСЕ Loop 
ImageSuchen: MOVEQ #0,D0 
MOVEQ #0,D1 
MOVE MousePosX,DO 
MOVE MousePosY,D1 
SUBQ #8,D0 
SUBI #24,D1 
DIVU #48,D0 
DIVU #32,D1 
MOVE DO,MousePosX 
MOVE D1,MousePosY 
MULU #13,D1 
ADD D0,D1 
MOVE.B D1,ImageNum 
MOVE MousePosX,DO 
MULU #48,D0 
ADDQ # 8,00 
MOVE DO,MousePosX 
MOVE MousePosY,DO 
MULU #32,D0 
ADDI #24,D0 
MOVE DO,MousePosY 
LEA ImageTabelle,AO 
MOVEQ #0,D0 
MOVE.B ImageNum,DO 
MOVE.B (А0,р0),р1 
MOVE.B D1,ImageZeichnen 
TST.B D1 
BEQ Loop 
BCHG #0,Zeiger 
BEQ Imagei 
MOVE.B Di,Karte 
ImageZeigen: MOVEQ #0,D0 
LEA ImageTabelle,AO 
MOVE.B ImageNum,DO 


100 


‚Zähler 
‚Zähler 


;1.Pointer 

;setzen 

;Bild aufbauen 
;Menue angewählt ? 
;Menue auswertung 
Taste gedrückt ? 
;Karte aufdecken 
;Userport-Zeiger 
;SignalBit UNSERTASK 
jWarte auf Ereignis 


3Ereignis. PORT 
;0 = Keine 


;Ereinis ADRESSE 
;hole Msg CLASS 

ақы НОТА CODE 
;EREIGNIS BESTÄTIGEN 
;war es ActiveWindow 


;Nein 
;Refreh Window 


;Zurück meist Loop 


;SpielProgAnf, 


;Mouse Y Position 
;Mouse X Position 


318% die Maus 
;auf dem 


‚Spielfeld ? 


;KarteNummmer? 
;Karte auf der 
;die Maus steht 
‚suchen 

jund 

;die Positionen 


;festhalten 


;Kartentabelle 


;KartenNummer 
;Karte holen 


;Karte schon offen ? 
;Nein 

;1.Karte ? 

;NEIN , 2.Karte 


MOVE.B #0,(A0,DO) 

BSR Bild 

TST.B Zeiger 

BNE Loop 

MOVEQ #$50,D1 
Linksys Delay,DosBase 
MOVE.B Karte ‚DO 

CMP.B Karte1,D0 

BEQ Paar 

LEA ImageTabelle,AO 
MOVEQ #0,D0 

MOVE.B ImageNum,DO 
MOVE.B Karte,(A0,D0) 
MOVE.B ImageNumi,DO 
MOVE.B Kartel,(A0,D0) 
MOVE MousePosxX, XImage 
MOVE MousePosY, YImage 
LEA ImageDaten, Al 
BSR ZeigImage 

MOVE  MousePosx1,xImage 
MOVE MousePosy1,yImage 
LEA ImageDaten,A1 
BSR ZeigImage 
MOVE.B #0,KartenPaar 
MOVE.L WindowBase,A0 


;Karte offen 
;Karte laden 


;2.Karte holen 

;Zelt Karten lóschen 
;Warte und lass andere 
jtasks arbeiten 
;Karten vergleichen 
jist es ein Paar ? 


;NEIN ‚ist kein Paar 
;Karten zurück in 
;Kartentabelle 


;Karten auf Screen 
;Löschen 


j 


Linksys ClearPointer,IntuitionBase ;alter Pointer 


MOVEQ #0,D0 
MOVE.B SpielerNR,DO 
CMP.B Spieler,DO 
BNE NextPL 
MOVE.B #0,SpielerNR 
LEA Pointer,Al 
BSR SetSprite 
BRA ZugZL 

NextPL: ADDQ.W #1,D0 
MOVE.B DO,SpielerNR 
MULU #44,D0 
LEA Роіпбег,А1 
ADD.L 0,41 
BSR SetSprite 
BRA ZugZL 

Paar: MOVE.B #1,KartenPaar 
MOVE MousePosX, Image2X 
MOVE MousePosY, Image2Y 
LEA Image2,A1 
BSR ZeigImage 


` 


pe 


;Wer ist am Zug 


ж 
;Paar Zähler 


;Paar Löschen 


Paar2: MOVE MousePosX1, Image2X 


MOVE MousePosY1, Image2Y 

LEA Image2,A1 

BSR ZeigImage 

MOVEQ #0,D0 

MOVEQ #0,D1 

MOVEQ #1,D2 

MOVE.B SpielerNR,DO 

BSR PAARZL1 

SUBQ.B #1,PaarZähler 

TST.B  PaarZühler 

BNE Loop 

MOVE ZugNR,DO 

MOVE HiZL,D2 

CMP D2,D0 

BGE HiEintrag 

MOVE DO,HiZL 

BSR TagesHiZL 
HiEintrag: MOVE ZugNR,DO 

MOVE.L HiZahlTab,A0 

MOVE.L HiTextTab,Al 

MOVE 18(A0),D1 

CMP р1,ро 

BCE Loop 

MOVE.L 36(A1),A3 

MOVE.L A3,StrInfo 

ADDQ.L #6,StrInfo 

MOVEM.L D0/D1/D2/A0,-(SP) 

MOVE.L A3,A0 

ADDQ.L #1,A0 

BSR UmRechnen 

MOVEM.L (SP)+,D0/D1/D2/A0 
HiLoop: MOVE (A0)+,Di 

MOVE.L (А1)+,А2 

CMP D1,D0 

BGE HiLoop 


;Paar gefunden 

;Alle Karten offen ? 
3NEIN , noch Karten dar 
;Alle Paare gefunden 


;TagesHi ? 
‚Ja 


;Hi-Score? 
‚Ja 


;Wo eintragen? 
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SUBQ.L #2,A0 
SUBQ.L #4,A1 
HiLoop1: MOVE.L (A1),A2 
MOVE.L A3,(A1)+ 
MOVE.L A2,A3 
MOVE (A0),D1 
MOVE DO, (A0)+ ;Einträge aufrücken 
MOVE D1,D0 
TST (A0) 
BNE HiLoopi 
MOVE  #34,ReqL 
MOVE.L #StrText2,StrT ;Name holen 
BSR Reql 
MOVE.L HiTextTab,A0 ;0ffset Speicher 
MOVE.L HiTextSpe,DO jminus 
MOVEQ #9,D1 
Hi0F2: SUB.L рО, (А0)+ 
DBRA D1,H10F2 
MOVE.L: #HiSpeicher,Buffer ;Hi auf Disk schreiben 
MOVE.L #FileHI,D1 
MOVE.L #566,D3 
BSR Schreiben 
MOVE.L HiTextTab,AO ‚Offset Plus 
MOVE.L HiTextSpe,DO 
MOVEQ #9,D1 
HiOF3: ADD.L DO,(AO)+ 
DBRA | Di,Hi0F3 
BRA HiBild ;Hi-Score Zeigen 
Image1:_MOVE.B Di,Kartel 
MOVE MousePosX,MousePosX1 
MOVE MousePosY,MousePosYl ;1. Karte merken 
MOVE.B ImageNum,ImageNumi 
BRA ImageZeigen 
Bild: MOVE mouseposx,pic2x 
MOVE mouseposy,pic2y 
MOVEQ #0,D0 
МОУЕ.В ImageZeichnen,DO 
MULU #768,D0 ;Karte auf 
SUBI.L %768,00 
MOVE.L imagepici,ai 
ADD.L  D0,A1 
MOVE.L A1,PicAdr ;KartenDaten” 
LEA Ріс2,А1 
ВВА ZeigImage jzeig sie 
ZeigImage: MOVE.L RastBase,AO  ;RasPort Zeiger 
MOVEQ #0,D1 sy Offset obere 
MOVEQ #0,D0 , ` jX linke Ecke im Screen 
Linksys DrawImage, IntuitionBase 
RTS . 
ZugZL: MOVE ZugNR,DO 
ADDQ #1,D0 
MOVE DO,ZugNR 
BSR ZugZL1 
BRA Loop 
ZugZL1: LEA PL21,A0 
BSR UmRechnen 
LEA PL2,A2 
MOVE.L #$15000e4, (А2) 
BSR Print 
RTS 
TagesHiZL: LEA PL21,A0 
BSR UmRechnen 
LEA PL2,A2 
MOVE.L #$21000e4, (А2) 
BSR Print ў 
RTS 
PaarZLi: LEA PaarZL,AO 
MOVE.B (А0,00),01 
ADD D2,D1 
MOVE.B D1,(A0,D0) 
MULU #96,D0 
SWAP Do 
ADDI.L #$f000f4,D0 
MOVE.L DO,PL2 
MOVE.L D1,DO 
LEA Р121,10 
UmRechnen 
P121,A0 
ж” ",(A0) 
P12,A2 
Print 


` 
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Spe 


UmRechnen: CMP #999,D0 ;In ASCII Zeichen 
BLS Rechnen 
MOVE.L %999,00 ;AO = Buffer 
Rechnen: MOVEQ #1,D1 32*loop 
MOVEQ #100,D2 ;Erster Teiler 
R1: DIVU D2,D0 
ADDI #930,00 
MOVE.B DO, (А0)+ ‚Buffer Plus 
DIVU #10,D2 
MOVE #0,D0 
SWAP DO 
DBRA D1,R1 
ADDI #$30,D0 
MOVE.B ро, (А0) 
RTS 
SetSprite: MOVE.L WindowBase,A0 
MOVEQ #16,D1 ;Größe in Pixel 
MOVEQ #9,D0 
MOVEQ #-3,D2 jHotSpod 
MOVEQ #-3,D3 
Linksys SetPointer,IntuitionBase 
RIS 
Finit: MOVE.L ScreenBase,A0 
ADD.L #44,А0 ;ViewPort 
LEA СМар,А1 ;ColorData 
MOVEQ #$14,D0 
Linksys LoadRGB4,GfxBase jColor setzen 
RTS 
Print: MOVE (A2)+,D0 
MOVE (A2)+,D1 ;X und Y Posi. 
Print2: MOVE.L (A2)+,TPL ;welcher Text^ 
LEA Plt,Al ;Textstruk.” 
BRA PIText 
Printi: MOVEQ #0,D0 
MOVEQ #0,D1 ;X und Y Posi. 
LEA Fts,Al ;Textstruk. 
PIText: MOVE.L RastBase,A0 
Linksys PrintIText,IntuitionBase ;Text ausgeben 
RTS 


Loop3: MOVE D7,D6 ;IN Bits 0-4 Titel-NR. 
AND #$1f,D7 ;IN Bits 5-10 Punkt-NR 
CMP #$1f,D7 ;IN Bits 11-15 UnterPunkt 
BEQ 100Р ;MenueTitelNR. keins = 1f 
LSR #5,D6 

#33f,D6 ;MenuePunktNR 0-2 
D7 
Menuel 302 
#1,D7 i### Welches von 3 Menus 
Menue2 31? 
Menue3 ikann nur 2 sein 
#1,D6 ;Item Suchen 
CLSP ;Neues Spiel? |, 
#3,D6 
1оор1 30011? 
D6 
Hibild ;Hi-Scores zeigen? 
#1,ImageZeichnen ;About zeigen 
SpielBild2 
SB2T1,A2 
MOVEQ #3,D2 

SB2Text: BSR Print 
DBRA D2,SB2Text 

HiBild1: BSR Wait 
MOVEM.L D6/D7,-(SP) 

BSR SpielBild 
MOVEM.L (SP)+,D6/D7 
СМР #$100,D6 
BEQ LOOP3 

BRA LOOP 

Menue2: CMP.B Spieler,D6 jWieviel Spieler 
BEQ Loop 
MOVE.B #0,SpielerNR 
MOVE.B D6,Spieler 

С15Р: MOVE.L WindowBase,A0 
Linksys ClearPointer,IntuitionBase 
BRA Neu 

Menue3: TST D6 
BNE M32 ;War es Saven? 


Listing 1. (Fortsetzung) 
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| 
| MOVE.L #StrBuffer,StrInfo ;Nein Laden 
| BSR Reqi jWas rn 
Bra IffRead ;Lade 
M32: MOVE.L #StrBufferi,StrInfo ;LeerBild ausgeben 
BSR Reqi ;wohin welcher Name 
MOVE.L #$1e00,D0 
BSR Allocate ;Speicher für Bildleer 
TST.L DO 
BNE LoopDaten ;Speicher frei 
MOVE.L #FehlerTexti,FT ;nein 
BSR FehlerR ;Fehler zeigen 
BRA Loop 
LoopDaten: MOVE.L DO,Buffer ;Daten aufbauen 
MOVE.L DO,AO 
MOVEQ #28,D0 
| LEA BildData,Ai 
LoopData: MOVE.L (A1)+,(A0)+ 
DBRA DO,LoopData 
MOVEQ #47,D0 
l LoopDatai: MOVE.L #$B100B100, (A0)+ 
DBRA DO,LoopDatai 
MOVEQ #2,D2 
LoopData2: BSR Data2 
MOVEQ „ #29,D0 
LoopData3: MOVEQ #12,D1 
MOVE # $100, (А0)+ 
LoopData4: MOVE.B #380, (A0)+ ;Vorsicht 
MOVE.B #$fd,(A0)+ ;Speicher zugriff 
| MOVE.B #0,(А0)+ ;ungerade Adresse 
MOVE.B #1,(A0)+ 
MOVE.B #1,(A0)+ 
DBRA D1,LoopData4 
MOVE.B #0, (A0) ;wird gerade 
BSR DATA3 
DBRA DO,LoopData3 
BSR Data2 
| DBRA D2,LoopData2 
| MOVE.L %159,00 
| LoopData5: MOVE.L #$В100В100,(А0)+ 
| DBRA П0,Іоорба%а5 
MOVE.L #StrBuffer1,D1 
| MOVE.L #$1e00,D3 
| BSR Schreiben ;Bild ablegen 
| MOVE.L Buffer,Ai > 
| MOVE.L #$1e00,D0 
| Callsys FreeMen ;Speicher zurück 
| BRA Loop jWeiter 
Schreiben: MOVE.L #1006,D2 ++ 
| Linksys Open,DosBase 
MOVE.L DO,FileHD 
BNE Schreib 
BSR FehlerRR 
BRA SchreibenEnd 
Schreib: MOVE.L FileHD,D1 ;Daten ablegen 
MOVE.L Buffer,D2 
Linksys Write,DosBase 
BPL SchreibEnd 
BSR FehlerRR 
SchreibEnd: MOVE.L FileHD,D1 
Linksys Close,DosBase 
SchreibenEnd: RTS ж-е 
| FehlerRR: Linksys IoErr,DosBase ;*** 
LEA FehlerText,AO 
BSR UmRechnen 
MOVE.L #FehlerText,FT 
FehlerR: BSR Printi 
MOVEQ #100,D1 
Linksys Delay,DosBase 
BSR SpielBild1 
RTS 
Data2: MOVE.L #$b3ff,(A0)+ 
MOVE #0,(A0)+ 
Data3: MOVE #$b100, (А0)+ 
MOVE.L #$b100b100, (AO) + 
RTS 
Кед1: MOVE.L WindowBase,A1 
LEA Requester, AO 
MOVE  RegL,RegC 
MOVEQ #0,D0 
Linksys Request, IntuitionBase 
TST.L DO 
BPL Req2 
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;SchreibFehlerTexte 


MOVE.L WindowBase,A1 
LEA Requester, A0 
Linksys EndRequest, IntuitionBase 


Reg3: MOVE.L (SP)+,D6 


BRA Loop 


Req2: MOVE #380,StOn 


MOVE.L WindowBase,A1 
LEA StGadget,AO 
LEA Requester,A2 
Linksys ActivateGadget,IntuitionBase 
BSR Wait 

CMP 3* $1000, De 

BNE Req2 

MOVE  #50,ReqL 

MOVE.L #StrText,StrT 

MOVE.L StrInfo,A0 

MOVE.B (А0),00 

TST.B DO 

BEQ Reg). 

RTS 


;Requester ausgeben 


SpielBild: MOVE.L ScreenBase,AO ;Alles Schwarz Setzen 


ADD.L — 344,40 

MOVE.L I2,A1 

MOVEQ #20,D0 

Linksys LoadRGB4,GfxBase — , 

MOVE.L RastBase,Al ;Bitmaps löschen 
MOVEQ #0,D0 

MOVEQ #0,D1 

Linksys MOVE,GfxBase 

MOVE.L RastBase,Al 

Linksys ClearScreen,GfxBase · 


ӛріе1В1141: Callsys Forbid ;Bild aufbauen 


MOVE #0,xImage 
MOVE #32,bImage ;Spielbild 
MOVE #16,Half 
MOVE.L #Ziegel_Karte,kImage 
MOVEQ #19,D3 
MOVEQ #19,D4 
MOVEQ #32,D7 
MOVEQ #16,D6 
MOVEQ #0,D5 
MOVEQ #0,D2 
MOVE #0,yImage 
BSR Image 
MOVE #$e0,yImage 
MOVEQ #1,D2 
BSR Image 
MOVE #48,bImage 
MOVE #32,Half 
MOVE.L #AH_Karte,kImage 
MOVEQ #12,D3 
MOVEQ ` #12,D4 
MOVEQ #8,D5 
MOVEQ ‘#5,D2 
#48,D7 
#32,D6 
#8,xImäge 
#24 ,yImage 
ImageTabelle,A3 
Image4 
TST.B Zeiger 
BEQ Weiterl ;War Karte offen? 
MOVE MousePosX1,MousePosX ;Ja 
MOVE MousePosY1,MousePosY 
MOVE.B Kartel,ImageZeichnen 
BSR Bild 


Weiterl: BSR SpText ;Texte Spielbild 


BSR Finit ;Farben normal 
Callsys Permit 
RTS 


SpielBild2: Callsys Forbid ;Bild Hi/About 


MOVE #0,xImage 

MOVE #0,yImage 

MOVE  #32,bImage 

MOVE #16,Half 

MOVE.L #Ziegel Karte,kImage 
MOVEQ #19,D3 

MOVEQ #19,D4 

MOVEQ #32,D7 

MOVEQ #16,D6 
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SPIELE 


MOVEQ #0,D5 D2,D1 
MOVEQ #15,D2 PRINT2 
BSR Image #12,D2 
BSR SpielBild21 D3,Bild2Text 
Callsys Permit HiBild1 jwarte Taste 
RTS 
SpielBild21: MOVE #8,MousePosX 
MOVE #17,MousePosY НіМец: MOVE.L HiZahlTab,AO 
MOVEQ #12,D2 MOVEQ #9,D1 
MOVEQ #1,D3 Hill: MOVE #999, (А0)+ 
Bild21: BSR Bild DBRA D1,Hili 
ADDQ.B #1,ImageZeichnen > MOVE.L HiTextTab,AO 
ADDI #48,MousePosX MOVE.L HiTextSpe,A1 
DBRA D2,Bild21 MOVEQ #9,D1 
MOVE #8,MousePosX Н112: MOVE.L A1,(A0)4 
MOVE #209,MousePosY ` ` ADD.L #50,А1 
MOVEQ #12,D2 DBRA D1,Hil2 
DBRA D3, Bild21 MOVEQ #9,D1 
! MOVE #49 ,MousePosY MOVE.L HiTextTab,AO 
` MOVEQ #4,D2 Н114: MOVE.L (А0)»,А2 
MOVEQ #1,D3 LEA HiName,A1 
Bild22: BSR Bild MOVEQ #40,D0 
ADDQ.B #1, ImageZeichnen Н113: MOVE.B (A1)+,(A2)+ 
ADDI #32,MousePosY DBRA D0,H113 
DBRA D2,Bild22 DBRA D1,Hil4 
MOVE #584 ‚MousePosX RTS 
MOVE #49,MousePosY 
MOVEQ #4,D2 
DBRA D3,Bild22 IffRead: MOVE.L #StrBuffer,D1 Filename 
RTS” BSR OpenFile 
Image: LEA ImageDaten,A1 ;Zeiger Image-Struktur MOVE.L #Buffer,D2 ;File gefunden 
BSR ZeigImage MOVEQ #8,D3 
ADD D7,xImage ;x Offset Image erhöhen BSR Load ;Iff-Form? 
DBRA D3, Image MOVE.L #Buffer,A3 
MOVE D4,D3 CMP.L # "FORM^,(A3) 
MOVE D5,xImage BNE FormFehler ;Fehler 
ADD D6,yImage ;y Offset Image erhöhen MOVE.L 4(A3),A3 
DBRA D2,Image MOVE.L A3,DO 
RTS BSR Allocate ;Speicher Bilddaten 
Image4: TST.B (А3)+ TST.L DO 
BEQ NoImage BEQ AllocFehler ;Fehler fragen 
LEA ImageDaten,A1 ;Zeiger Image-Struktur MOVE.L DO,Buffer 
BSR ZeigImage MOVE.L A3,D3 
NoImage: ADD D7,xImage ;x Offset Image erhöhen MOVE.L Buffer,D2 
DBRA D3, Image4 BSR Load ;Lade Bild 
MOVE D4,D3 BSR CloseFile ;File schliessen 
MOVE D5,xImage ` IffTest: MOVE.L Buffer,AO jBildAnfang 
ADD D6,yInage ;y Offset Image erhöhen MOVE.L AO,BildAnfang 
DBRA _ D2,Image4 MOVE.L (A0),DO 
RIS ў, CMP.L — $* "ILBM^,DO jGrafik? 
SpText: LEA SpT,A2 ;Texte Spielbild zeigen BildFehler ;Fehler 
MOVE.B Spieler,DO 12(A0),DO 
ADDI #$31,D0 #$280,D0 3640 Punkte BREIT ? 
MOVE.B DO,SpTi BildFehler ;Fehler 
Print MOVE.B 20(А0),ро 
SpT2,A2 CMP.B #4,D0 ;4 BitPlane ? 
Print BNE BildFehler ;Fehler 
Titel,A2 MOVE.B 22(A0),GePackt 
Print CMaps: MOVE (A0)+,DO pase 
HAT, A2 CMP.L ж “CMAP”, (AQ) ;Farben suchen 
Print BNE CMaps 
ZugT,A2 ADD.L ж20,10 ;5 Farbe im File 
Print MOVEQ #11,D0 
ZugNR,DO LEA СМар,А1 ;ColorTabelle Spiel 
205211 ADDQ.L #8,А1 ;5 Farbe in Tabelle 
HiZL,DO Farben: MOVEQ #0,D1 
TagesHiZL MOVE.B (A0)*,Di 
#0,D3 LSL #4,D1 
MOVE.B Spieler,D3 MOVE.B (А0)+,01 ;Farben lesen 
: MOVEQ #0,D1 LSL #4,D1 
| MOVEQ #0,D2 MOVE.B (А0)-,01 
MOVEQ #0,D0 LSR #4,D1 
l MOVE D3,D0 MOVE D1, (A1)+ 
Рааг А D0,Farben IECH 
D3,Pzs IffBody ‚Bilddaten Suchen 
1 A BPlane ;In Bitplanes Schreiben 
HiBild: MOVE.B #4,ImageZeichnen ;Hibild zeigen KEinlesen ;Imagedaten Aufbauen 
BSR SpielBild2 Free ;Speicher frei 
MOVE.L HiTextTab,A2 Neu ;AusSprung IffRead 
MOVEQ #9,D3 BPlane: MOVE.L 5сгеепВазе,А0 ;Bitplaneadr. ermitteln 
MOVEQ #70,D2 
Bild2Text: MOVE.L #159,D0 ;Texte zeigen Listing 1. (Fortsetzung) 
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ADD.L #$с0,А0 
LEA PlaneBuf,A1 
MOVEQ #3,D0 
PlaneNum: MOVE.L (AO)+,(A1)+ 
DBRA 00,Р1апепип 
BildAusgeben: MOVE.L BildAnfang,AO 
MOVE #24,ZeileNum ;Ab hier Schreiben 
LEA PlaneBuf,A1 
Weiter: MOVE.L (A1),A2 
BSR Zeile 
MOVE.L 4(A1),A2 
BSR Zeile 
MOVE.L 8(А1),А2 
BSR Zeile 
MOVE.L 12(А1),А2 
BSR Zeile 
ADDQ #1,ZeileNum 
СМРІ #150,zeileNum 
BNE Weiter 
RTS ;Fertig IffBild 
Zeile: MOVEQ #79,D0 ;IffDaten schreiben 
MOVE ZeileNum,D1 jins Bild 
MULU #80,D1 
ADD.L DAS 
TST.B GePackt 
BNE PLoop 
Zeilei: MOVE.B (A0)+,(A2)+ 
DBRA р0,2е11е1 
RTS 
PLoop: MOVEQ #0,р1 
MOVE.B (AO)+,D1 
BMI Packed 
Plus: MOVE.B (А0)+,(А2)+ 
SUBQ #1,D0 
DBRA D1,Plus 
BRA Test 
Packed: CMPI #128,D1 
BEQ Ploop 
NEG.B Di 
MOVE.B (А0)+,02 
PackLoop: MOVE.B D2,(A2)+ 
SUBQ.B #1,D0 
DBRA рл1,раск1оор 
Test: TST.B DO 
BPL Ploop 
RIS ‚Zeile fertig 
IffBody: MOVE.L BildAnfang,AO 
IffLoop: MOVE (A0)+,Di 
MOVE.L (А0),р1 
CMPI.L #$424£4459,D1 
BNE IffLoop 
ADDQ.L #8,А0 
MOVE.L AO,BildAnfang 
RTS 
KEinLesen: MOVE.L #1,KAnfang 31%8 Bit SeitenAbstand 
MOVE #48,ZeileNum ;AnfangsZeile 
MOVE.L ImagePic1,A3 
MOVEQ #2,D4 
LEA PlaneBuf,AO 
EinLeseni: MOVEQ #12,D3 
EinLesen: MOVE.L (A0),Ai 
BSR Lesen 
MOVE.L 4(A0),A1 
BSR Lesen 
MOVE.L 8(A0),A1 
BSR Lesen 
MOVE.L 12(А0),А1 
BSR Lesen 
ADDQ.L #6,KAnfang ;Nächste Karte 6*8 Bits 
DBRA D3,Einlesen 313 Karten 
ADDI #32,ZeileNum 
MOVE.L #1,KAnfang 
DBRA D4,EinLeseni 
RTS 
Lesen: MOVEQ #0,D0 
MOVE ZeileNum,DO 
MULU #80,D0 
ADD.L —KAnfang,DO 
ADD.L 0,41 
MOVEQ #31,D2 
Leseni: MOVEQ #5,D1 


;4 Planeadressen 


;bis Hier Einlesen 


;Body Chunk suchen 


313% KartenScreen 


;ImageDaten aufbauen 


;32 Bits KartenHöhe 
36%8 Bits KartenBreite 


Lesen2: MOVE.B (A1)+,(A3)+ 
DBRA — Di,Lesen2 
ADD.L #74,А1 
DBRA D2,Lesen1 
RTS 

OpenFile: MOVE.L #1005,D2 
Linksys Open,DosBase 
TST.L DO 
BEQ OpenFehler 
MOVE.L DO,FileHD 
RTS 

Load: MOVE.L FileHD,D1 
Linksys Read,DosBase 
TST.L DO 
BMI ReadFenler 
RTS 


Allocate: MOVE.L #$10000,D1 


Callsys Allocmem 
RTS 3 
CloseFile: MOVE.L FileHD,D1 
Linksys Close, DosBase 
RTS 
Free: LEA Buffer, A0 
MOVE.L (А0)+,А1 
MOVE.L (А0),00 
Callsys FreeMem 
RTS 


;REG D1 FileName” 


;Fehler Fragen 


;Reg D3 Lange lesen 
;Reg D2 Buffer 


;Fehler fragen 


` 
AllocFehler: MOVE.L #FehlerTexti,FT 11! 


BSR CloseFile 
BSR Warte 

BildFehler: BSR Free 
BRA BFehler 


FormFehler: BSR CloseFile ;FehlerTexte Load 
BFehler: MOVE.L #FehlerText2,FT ;IffBild 


BSR Warte 


ReadFehler: BSR CloseFile 


OpenFehler: Linksys IoErr,DosBase 


LEA FehlerText,A0 

BSR UmRechnen 

MOVE.L #FehlerText,FT 
Warte: MOVE.L (SP)+,D6 

BSR Printi 

BSR Wait 

BRA Neu 


НІШ 


SetMenu: LEA MenuTabelle,AO ;` auf MenuePunkte 


LEA Nep, AL 
MOVEQ #10,D1 
MenuLoop: MOVEQ #0,D2 
MOVE.L A1,A2 
TST.L (А0) 
BEQ SetMenul 
MOVE.L #0,(A1)+ 
MOVE 0р1, (А1)+ 
ADDI.L #80,D1 
MOVE.L #80, (A1)+ 
MOVE.L #$a0001, (A1)+ 
MOVE.L (А0)+,(А1)+ 
LEA 12(A1),A3 
MOVE.L A3,(A1)+ 
MOVE.L #0, (А1)+ 
MOVE.L #0,(A1)+ 
ItemLoop: TST.L (А0) 
BEQ | MenuEnd 
LEA 54(A1),A3 
MOVE.L АҘ, (А1)+ 
MOVE.L D2,(A1)+ 
ADDI #10,D2 
MOVE.L #$70000a, (A1)+ 
MOVE  #$92,(А1)+ 
MOVE.L #0,(А1)+ 
LEA 16(A1),A3 
MOVE.L A3,(A1)+ 
MOVE.L #0,(А1)+ 
MOVE.L - #0, (А1)+ 
MOVE.L #0,(А1)+ 
MOVE.L #$3020100, (A1)+ 
MOVE.L #$50001, (A1)+ 
MOVE.L #0,(A1)+ 
MOVE.L (А0)+,(А1)+ 
MOVE.L #0,(A1)+ 
BRA ITEMLOOP 
MenuEnd: MOVE.L #0,-54(A1) 


; auf MenueStrukturBuffer 
3X Position 

Di 

Buffer’ retten 

;Menues fertig ? 

;JA =MenuesDarstellen 
;MenueTitel fertig 


;X Pos erhöhen 

;Y Pos und breite 
;höhe und Flags 
;MenueTitel 


У Menueltens 


;Letzter Eintrag ? 
;JA Menue fertig 


; nächsten Item 
3X Y Pos 

;Y Pos erhóhen 
jbreite höhe 
jFlags 

;kein Ausschluss 


у TextStruk. 

;keine FüllStruk. 

;kein Kommand/UnterMenue 
jkeine fortsetzung 
;TextStruk/Farbe/Mode 
;X Y Pos 

; Font 

; Text Item 

jkeine fortsetzung 
;nächstes Item 
;nächster Punkt löschen 
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TST.L (А0)+ ; Tabelle erhöhen Window: DC.W 0,0,640,256 ;x/y -Offset, Breite, Höhe 
TST.L (А0) ;noch ein Menue ? DC.B 3,2 ;Pen farbe 
BEQ SetMenul ‚mein fertig DC.L $41188 ‚Flags 
MOVE.L A1,(A2) nächstes Menue DC.L $9а00 3IDCMP Flags 
BRA MenuLoop ;aufgehts DC.L 0,0 ‚Gadgets , Checkmark 
SetMenul: MOVE.L МіпдоыВаве,А0 ;Menue Initialisieren DC.L PL2 ;Textzeiger 
LEA Menu, AL ScreenBase: DS.L ;Screenzeiger 
MOVE.L #276,D0 DC.L 0 ;Bitmap 
MOVE 3 $193, 12(A1,D0) DC.W 0,0,0,0 jmin/MAX Breite/Höhe 
MOVE.L #$fffe,14(A1,D0) DC.W 15 ;Type l=workb 15=custom 
ADDI #54,D0 N 
MOVE  #$93,12(a1,D0) Эжен REQUESTER STRUKTUR 3:9 900]0ddgd|anmedddere 
MOVE.L #$fffd,14(a1,D0) 
ADDI #54,D0 Requester: DC.L 0 ;Vorgänger 
MOVE #$93,12(a1,D0) DC.W 200,100 ;Links/Oben 
MOVE.L #$fffb,14(a1,D0) DC.W 240,40 ;Breite/Hóhe 
ADDI #54,D0 DC.W 0,0 ;Pointer bezugspunkt 
MOVE #$93,12(a1,D0) DC.L  StGadget ; Gadget 
MOVE.L #$ff£7,14(a1,D0) DCL 0 i Border 
LINKSYS SetMenuStrip,IntuitionBase DC.L StringText ;jIntui.Text Struk. 
RTS DC.W $4 ;Flags 2 
DC.B 1,0 ;Backpen/pad 
OOOO 000000008 DATEN UND STRUKTUREN 30000000 DL 70 j Layerstruk. 
DS.B 32 ;Рай1 System use 
Align.L DC.L ; Custom BitMap 
FileHD: DC.L ;RWindow 
OldDir: " DS.B 36 ;Pad2 System use 
CDDir: 
IntuitionBase: кке String Gadget Struktur женененненененене 
WBenchMsg: 


Initial SP STGADGET: DC.L 0 ;Nächstes Gadget 
DosBase: * DN ` 20,20,200,10 ;X/Y Pos// Breit/höhe 
GfxBase: StOn: DC.W $0,$204,$1004 ;Flags//Activation//Typ 
WindowBase: 3 Borderstruk. 
UserPort: ;select Zeichnung 
RastBase: j Textstruk. 

ImagePic1: ;Execlute 

Kanfang: У Stringinfostruk. 


Planebuf: ‚Gadget ID 
Bildanfang: ;User Data 
PaarZL: 


BUFFER: StrInfo: DC.L  StrBuffer  ;'Buffer 


HiZahlTab: DC.L pundo Buffer 
HiTextTab: ReqC: DC.W ;Cursor-Pos 
HiTextSpe: ReqL: DC.W ;Max.Char 


;Speicher für 

;Werte im 

MousePosX1:- ;Programm lauf StringText: DC.B 0,1,1,0 ;Textstruk. 
MousePosY1: DN 8,8 

HAZL: GL 0 


ZugNR: StrT: DC.L StrText 
SpPaare: DC.L 0 


Karte: 
Kartel: StrBuffer: DC.B "MEMO. PIC^,0 


ImageNum: BLK.B 50 
ImageNumi: 


Zeiger: StrBufferl: DC.B "MEMORY -LEER-BILD",O 
PaarZähler: BLK,B 50 

KartenPaar: 

Spieler: 


SpielerNR: StrText: DC.B "BITTE PFAD/FILENAME EINGEBEN",0 

Gp: Align.W 

GePackt: StrText2: DC.B ">>> BITTE NAMEN EINGEBEN << « ",0 
Align.W 

; ##ЗӨЗӨӨӨӨНӨ RAN Menue Daten JJ3J)ee||d|edadadaagngnee 


MousePosY 


RR ScreenStruktur JAE 
Align.W 


Screen: DC.W 0 jobere linke Ecke x MenuTabelle: DC.L · Menui ;MenueTitel 1 


DC.W 0 ;obere linke Ecke y i DC.L MP11,MP12,MP13,MP14 ;Item Punkte 
DC.W 640 ;Screen breite x Punkte DC.L 0 ;Menue 1 Endeflag 


DC.W 256 ;Sereen höhe у Punkte DC.L Menu2 
DOW 24 apen DC.L МР21,МР22,МР23,МР24 
DC.B 0 ;Pen DL ^0 

DC.B 0 ;Back Pen DC.L ^ Menu 
DC.W $8000 ;ViewMode DC.L — MP31,MP32 
DO. 15 ;CustomScreen (1=Workb) DL o 

D.L 0 ;Font (0-Systemfont) D.L 0 

DC.L — STitel ; Titel 

DC.L 0 ‚Gadgets эке 
DL 0 ;BitNaps 


;Ende Flag ganzes Menue 


Texte zu den Menues und Items Эжен 


PERGHHH WindowStruktur HERR Listing 1. (Fortsetzung) 
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Menui: DC.B ^ MEMORY ”,0 ZugT: DC.L $f000e4,ZugTi 


MP11: DC.B ” ABOUT ”,0 Intui: DC.B "intuition. library”,0 
MP12: DC.B “START ^,0 Dos: DC.B ^dos.library",0 
MP13: DC.B ” HI-SCORE ”,0 Gfx: DC.B "graphies.library",0 
MP14: DC.B "QUIT ^,0 FileHI: DC.B "MEMORY-HI”,O 
HiName: DC.B *> <-> HI- SCORE NAME BITTE < <<<”,0,0 
Menu2: ” PLAYER ",0 FehlerText: DC.B * FEHLER ** DOS "0 
MP21: " 1 SPIELER FehlerTextl: DC.B E KEIN SPEICHER FREI ”0 
” 2 SPIELER FehlerText2: DC.B ” FALSCHES BILD (FORMAT) ”,0 
” 3 SPIELER : "  SPIELER",0 
MP24: " 4 SPIELER HES. 
the hss 
Menu3: . KARTEN ”,0 ^ PAARE ”,0 
MP31: . IFF - LADEN ”,0 Titell: DC.B "AMIGA-MEMORY”,O 


MP32: . IFF - SAVEN ”,0 HiT1: DC.B ” TAGES-HI.: 000”,0 
ZugTi: DC.B. ^" ZUG.NR.: 0007,0 
REENEN TMAGESTRUKTUR ХХХ STitel: DC.B "SCREEN^,0 
Align.W 582712: DC.B "VERSION 2.0 14. 4. 1989",0 

ImageDaten: SB2T13: DC.B "GESCHRIEBEN VON ANDREAS HERCKNER”,O 
XImage: DS.W зх und y offset SB2T14: DC.B "COPYRIGHT ВЕНІЛМ”,0 
YImage: DS.W. ImageZeichnen: DC.B 0,0 
BImage: DC.W ‚Größe in Pixel 
Half: DC.W Align.W 

Dc. ;Bitplanes (depht=farben) SB2T1: DC.L $480064 , Titel1 
KImage: DC. ;Zeiger auf Image DC.L %480074,5В2712 

DC. jin welcher Bitplane DC.L $b80084 ,SB2T13 

Dc. ;Bitplane ausfüllen Farbe DC.L $£80094 , SB2T14 

Dc. ;nüchste ImageSTRUK. 

Эжен DATA muß ins ChipRam GeLinkt werden кенен 

Image2: Data 
Image2x: DS.W AH_Karte: DC.L 800000000, 00000000, $00000000, $3fffffff 
Image2y: DS.W $fffo3fff,Sfffffffc,$30000000,$00003000 
$0000000c,$30000000, 900023000, $0000000c 
$30000000, $000¢3000 , $0000000c , $30000000 
$000c3000, $00000000 , $30000000 , $000¢3000 
$0000000« , $30000000 , $000c3000 , $0000000c 
$30000000, $000c3000, $0000000c , $30000000 
$00003000, $0000000c , $30000000, 800063000 
$0000000c , $30000000, $000c3000, $0000000c 
$30000000, $000¢3000 , $0000000c , $30000000 
$000c3000, $0000000c ,$3f f£ , $t fc3f ff 
.Sfffffffc,$00000000,$00000000,$00000000 
$00000000,$00007f ff ,$£ffffffe,97fffffff 
$fffe7fff ,Sfffffffe, 7f Pfffff,Sfffe7fff 
Sfffffffe,S7fffffff,Sfffe7fff,Sfffffffe 
S7fffffff,Sfffe7tff Sft fffffe, S70 Tff f7£ 
$fffe7fff ,Sfe7ffffe, 7f felo7f ,Sfffe7fff 
$8e7ffffe,97£f£c671,9?ffe7fff ,$a26e7ffe 
$7f£f£705f ,$3ffe7ffd,$e8313f fe, $7f f9do7£ 
$3ffe7ff9, $7e3f3ffe, $7ffdfelf, $3f fe7fff 
$fe7f3ffe, $7ffffe7e, S7f fe7f ff , Sf ffffffe 
S7tffffff ,Sfffe7fff ,Sfffffffe, $70РеРеРР 
$fffe7fff,Sfffffffe, 7t fff fff ,Sfffe7fff 
$fffffffe,S7tffffff,Sfffe0000,$00000000 


"Leer. Karte 


PicAdr: DS.L "Bilder Karten 
DC.B 15,0 
DC.L 0 


Кк Texts tru tur кн 


PLT: DC.B 3,2,1,0 3 PEN, BackPEN, MODE, ? 

DC.W 00,00 3 X und Y Pos 

Dol 0 jFontStruk.  O-Systemfont 
TPL: DS.L 4 ;TextZeiger ** 

DC.L 0 Nächste Textstruk.0-keine 


98 
1 
1 
L 
L 
Di 
1 
1 
1 
1 
L 
L 
L 
1 
Di 
1 
Di 
L 
Di 
1 
л 
1 
Di 


FTS: DC.B 1,0,1,0 ; PEN, BackPEN, Mode, ? Ziegel Karte: 00.1. $00000000,$00000000,$00000000,$02020800 
DC.W 808,974 ; X und Y Pos DC.L  $00000100,$00000400, $00400040, 800000000 
DCL 0 ;FontStruk.” O-Systenfont DC.L ^ $00000000,$00000000,$00000020,$01001010 
FT: DC.L ` Fehlertext ;TextZeiger YA ` ро. —$00000000,$04800400,$08000000, $00000000 
DCL 0 ;Nüchste Textstruk.O-keine DC.L ^ $00000000,8fffffffd $Pffffff,Sffferrfà 
DO.L — $fffFfffà,Sfffffffd ЗЕЕРЕРРҒа, Sf Ffffffa 
Смар: DC.W $000,$444,$00,$с8 DC.L ^ $00000000,$fffáffff Sfffàffff, $rffaffff 
DC.W — $040,$£0£,$0££,$0£0 00. Sfffdffff,Sfffüffff ,grrrarere,serearree 
DC.W — $fd8,$064,$ff0,$add " 
DC.W $879, $ecb, $999, $4ae Pointer: DC.W  0,0,$8810,$18,$5030,$30, $50, $78, $5090, $48 
DC.W — $000,$fff,$e00,$feb DC.W ^ $8910,$198,$10,$18,$10,$18,$10,$18,$10,$18,0,0 
DC.  0,0,$8878, $fe, $5084, $186, $84, $186, $5008, $C, $8810 
BildData: 00.1 946445244,000014(8,949404244,942444844 00.0 $18, $20,$30,$40,$60,$80,8fc,$1fc,$1fc,0,0 
DC.L  $00000014, $028000¢8, $00000000, $04020100 à DC.W — 0,0,$88fc,$fc,35102,1f,$2,$106,$5004,$c 
DC.L $00000800,$028000с8,$43414847,$00000004 DC.W — $8878,978,84,$6,82,8106,$102,$1fe,$/c,$£0,0,0 
DC.L ^ $00008000,$43444150,$00000030, $00000040 DC.W ^ 0,0,$8810,$18,$5020,$30,$40,$60,$5088, $c, $8908 
$40d0¢000, $00f0c080,$004000f0, $00£000£0 DC.W 918с,%208,266,6777,8744,8,5е,88,фе,0,0 
$2000£000,$f0d08040,$8040£0£0,300d0d040 
$807090e0, 800609090, $9040a0e0 BSS 
34244459,$0000148c ImageTabelle: BLK.W 40 
Menu: BLK.W ` 320 
$48, PL21 HiSpeicher: BLK.W 283 
35200е4,5рті 
5рт2: 00.1 $6000f4,SpT21 End 
Titel: DC.L %480004,715е11 
HIT: DO.L  $16000e4,HiT1 . d Listing 1. (Schluß) 
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Die Fachwelt steht 
Kopf. Ein Durch- 
bruch der Wissen- 
schaft. Die erste 
strahlungsfreie Ket- 
tenreaktion im Ho- 
mecomputer. 


Von Hans Waldhäusel 


paß beiseite, der AMIGA 
kann viel - es gibt sogar 
Leute, die davon über- 
zeugt sind, daß es (fast) nichts 
gibt, was dieser Super-Compu- 
ter nicht kann. Aber Kernspal- 
tung? Nun, zumindest als Spiel 
gibt's das wirklich. Jetzt! Hier! 
Im AMIGA-Sonderheft! 
»REAKTOR« ist ein Spiel für 
zwei. Ein Strategie-Spiel, bei 
dem die Action nicht zu kurz 
kommt. Ein Spiel, bei dem der 
Computer nur Werkzeug ist und 
gar nicht Gegner sein kann. 
Wenn Sie Gefallen an »REAK- 
TOR« gefunden haben, kom- 
men Sie nicht umhin, sich nach 
einem menschlichen Spielpart- 
ner (-gegner) umzusehen - ein- 
sam vor dem Computer sitzend 
hat es gar keinen Sinn, »REAK- 
TOR« zu starten. Es macht wirk- 
lich nur SpaB, wenn man einen 
Partner hat (oder spielen Sie 
gegen sich selbst Schach?). 
Auf einem  quadratischen 
Spielfeld sind 36 Atomkerne 
gleichmáBig verteilt (Bild 1). Die 
Spieler kónnen nun abwech- 
selnd - durch Anklicken - je- 
weils einen Kern pro Spielzug 
für sich in Besitz nehmen. Die 
Besitzverháltnisse werden 
durch Einfárbung der Kerne in 
der Farbe des Spielers (Rot oder 
Blau) dokumentiert. Gleichzei- 
tig wird mit jedem Anklicken 
dem Kern ein Neutron implan- 
tiert, wodurch die Masse des 
Kerns natürlich ansteigt. Und 
wie wir alle im Physik-Unterricht 
gelernt haben (oder noch ler- 
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Strategiespiel zu zweit 


nen werden): Wenn ein Atom- 
kern seine kritische Masse er- 
reicht - BUMM. 

Bei REAKTOR gelten folgen- 
de »Naturgesetze«: Ein Kern er- 
reicht dann seine kritische Mas- 
Se, wenn er mit so vielen Neu- 
tronen gefüttert wurde, als er 
Nachbarn hat (wobei nur dieje- 
nigen záhlen, die im rechten 
Winkel zum jeweiligen Kern ste- 
hen). Wir haben in Bild 1 zur 
Verdeutlichung einige signifi- 
kante Kerne mit ihren kritischen 
Neutronenzahlen gekennzeich- 
net. Macht es jetzt BUMM, so 
schleudert der explodierende 
Kern seine ihm zuvor aufge- 


Krieg 
n Kernen 


die Aufnahme des Fremdneu- 
trons seine kritische Masse, 
kommt es auch bei ihm zu einer 
Reaktion - BUMM-BUMM! Und 
so weiter. Ein Spiel ist dann 
beendet, wenn es nur noch un- 
besetzte und/oder besetzte 
Kerne einer Farbe auf dem 
Spielfeld gibt, wenn also alle 
Kerne des Gegners übernom- 
men wurden. Übrigens werden 
explodierte Kerne automatisch 
durch besitzneutrale ersetzt, so 
daßesschon eine Weile dauern 
kann, bis ein Spiel beendet ist. 
Erschwerend kommt noch hin- 
zu, daß Sie nicht unbegrenzt 
Zeit zum Überlegen haben. Zu 


Bild 1. »REAKTOR« - viel Spaß mit einfachen Mitteln 


pfropften Neutronen zu seinen 
Nachbarkernen, die diese in ihr 
Atomgefüge aufnehmen, so als 
wären sie angeklickt worden. 
So eine Neutronenaufnahme 
bedeutet aber auch, daß der 
beschossene Kern in den Be- 
sitz jenes Spielers übergeht, 
dessen Kern explodiert ist - die 
fremden Neutronen infizieren 
ihn gewissermaßen! Erreicht 
ein beschossener Kern durch 


Spielbeginn müssen Sie die zu- 
lässige Bedenkzeit je Zug ein- 
geben - und wenn diese abge- 
laufen ist, ohne daß Sie sich für 
einen Zug entschieden haben, 
kommt Ihr Gegner dran. Netter- 
weise erinnert Sie ein akusti- 
sches Signal in den letzten fünf 
Sekunden Ihrer Zeit daran, 
endlich etwas zu unternehmen. 

So simpel sich dieses Spiel- 
prinzip anhört - probieren Sie 


SPIELE 


es aus! »Mensch-ärgere-dich- 
nicht« ist auch simpel; und wie 
viele Stunden haben Sie damit 
schon verbracht? Uns hat 
»REAKTOR« ein wenig an Hal- 
ma erinnert, weil man fremde 
»Kernstraßen«, die der Gegner 
für eine Kettenreaktion aufge- 
baut hat, bei klugem Taktieren 
für sich benutzen und überneh- 
men kann. 

Und glauben Sie uns: Es ge- 
hört schon etwas Geistesakro- 
batik dazu, sich eine Kettenre- 
aktion soweit vorzustellen, daß 
auch wirklich das geschieht, 
was man erreichen möchte. All- 
zu leicht passiert es, daß die ei- 
gene Reaktion in einem Sta- 
dium zum Erliegen kommt, in 
dem der Gegner durch eine ge- 
schickt plazierte Explosion alle 
soeben verlorenen Kerne wie- 
der zurückerobert - und noch 
etliche mehr. 

So einfach das Spiel, so kurz 
das Programm (Listing 1). Sie 
sehen, man braucht für ein un- 
terhaltsames Spiel nur eine gu- 
te Idee und nicht unbedingt sei- 
tenlange Programme. Vermis- 
sen Sie lange DATA-Kolonnen 
oder ein nachzuladendes File 
für die Grafik? Sie vermissen 
richtig! Die Grafik wird »per Zu- 
fall« und mit Hilfe der Trigono- 
metrie jedesmal neu entwickelt. 
Das spart Ihnen Tipparbeit und 
dem AMIGA Speicherplatz. Er- 
kauft werden diese Vorteile 
durch eine etwas lästige Warte- 
zeit beim ersten Programm- 
start. Aber wer früher einen 
C64 ohne Beschleuniger in Ве- 
trieb hatte, wird über die 35 Se- 
kunden milde láchelnd hinweg- 
sehen. Wir haben für Sie die 
Grafik-Routine aus dem Haupt- 
programm herausgelöst und 
als  lauffáhiges Demo-Pro- 
gramm in Listing 2 abgedruckt, 
um Ihnen ein eventuelles Einbin- 
den in Ihre eigenen Programme 
zu erleichtern. Mit der ausführ- 
lichen Kommentierung dürfte 
das keine Probleme bereiten. 
Die Grafik-Berechnungen er- 
folgen natürlich wesentlich 
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schneller, wenn man dem Kern 
nicht eine so hohe Anzahl an 
Nukleonen (im Programm sind 
es 40) verordnet. Vielleicht fin- 
det sich auch ein REAKTOR- 
ianer, der die trigonometri- 
Schen Berechnungen in ein 


Reaktor als 
Baukasten 


Maschinensprache-Subpro- 
gramm umsetzt oder einen 
LIBRARY-Aufruf einbindet? - 
einen entsprechenden Nach- 
trag werden wir gerne veróffent- 
lichen. Eine leichte Beschleuni- 
gung (GróBenordnung ca. 20 
Prozent) erreichen. Sie, wenn 
Sie folgende Zeilen einbauen 
(diese Programmzeilen sind 
nicht Teil des Originalpro- 
gramms und daher auch nicht 
im File »REAKTOR« auf der Le- 
serservice-Diskette enthalten): 


DECLARE FUNCTION Find 
Task& LIBRARY 

LIBRARY "exec.library" 
task&-FindTask&(0) 
CALL SetTaskPri& 
(task&,120) 


Wenn Sie diese vier Pro- 
grammzeilen an den Anfang 
des Programms stellen und auf 
Ihre »REAKTOR«-Diskette noch 
das File »exec.bmap« kopieren, 
so erhóhen Sie die Task-Priori- 
tät und lassen die Berechnun- 
gen daher auch schneller 
durchführen. Wichtig dabei ist, 
daß Sie ab nun keine zeitkriti- 
schen Vorgánge, wie z.B. Dis- 
kettenzugriffe, durchführen, da 
Sie bei der im Beispiel angege- 
benen hohen Task-Prioritát von 
+120 bereits in die Bereiche 
des Betriebssystems hinein- 
pfuschen. Deshalb müssen Sie 
auch die Prioritátsverháltnisse 


DEFINT ne, р12, pl, ex, ey, xp, yp, xoff, yoff, i, уу, aa, xx, yy, 


v2, V22, ke, add 
SCREEN 1,640,256,4,2 


RANDOMIZE TIMER 


DIM r£(15),g2(15) ,b%(15) ‚anz%(10,10) ,max%(10,10) 


'Hires-SCREEN mit 16 Farben,ohne Rand 
WINDOW 2,””,(0,0)-(631,220),0,1 


'oder Gadgets beim WINDOW ! 


'Zufallsgenerator initialisieren 


'Feldvariablen 


DIM kern%(600,2) ‚exp1%(600) ,wav%(255) 


pi=3.1415 

FOR 1-0 TO 255 
wav%(1)=INT(RND*256-128) 

NEXT 

FOR 1-0 70 15 
READ т%(1),6%(1),5%(1) 
PALETTE 1,0,0,0 

NEXT 

PALETTE 2,5/15,0,12/15 


"Konstante 


'Zufallswellenf. fuer Rauschen 


'Farbwerte in Variablen lesen 
'Alle Farben schwarz 


'Bis auf Schriftfarbe 


COLOR 2,0:LOCATE 14,31:PRINT "Bitte Warten..." 


'Daten fuer RGB-Farbwerte im Bereich von 0 bis 15 


DATA 0,0,0,0,0,0 

DATA 9,8,5,13,12,9 

DATA 13,13,13,10,10,10 

DATA 7,7,7 

DATA 14,5,5,10,5,5 

DATA 6,5,5 

DATA 5,5,14,5,5,10 

DATA 5,5,6, 

DATA 0,0,5, 
D 


, 
› 

, 

0 TO 3 
xv(1),yv(1) 
NEXT 'rel.Positionen der Neutronen 
y einlesen 
DATA 0,-1,1,0,0,1,-1,0 
COLOR 2,0:GOSUB grafix 


FOR 1: 


newgame: 
CLS 
FOR i=0 TO 15 


"Neues Spiel 


PALETTE 1,r%(1)/15,8%(1)/15,b%(1)/15 


NEXT 
COLOR 2,0:LOCATE 14,15 


'Riehtungsvektoren (x/y) fuer 


'Grafik erzeugen 


'Farben richtig setzen 


PRINT "Welehe Bedenkzeit für jeden Zug (in Sekunden)...”; 


LINE INPUT t$:mt-VAL(t$):CLS 


'max.Bedenkzeit festlegen 


xan=6:yan=6:xoff=70:yoff=10 "Groesse und Position des Spielfelds 


FOR xx=0 TO хап-1 
FOR 0 TO yan-1 С 
хр-20%хх%60:ур-1%уу%30 


"Spielfeld aufbauen 


'Bildschirmpos. des Kerns 


max$ (xx, yy) =4+(хх=0)+(хх=(хап-1))+(уу=0)+(уу=(уап-1)) 


ап2%(хх,уу)-0 
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' ^ max.Anzahl der Neutronen dieses Kerns 


sobald als möglich wieder nor- 
malisieren, und zwar mit 

CALL SetTaskPri(task&,0) 
wobei unserer Meinung nach 
der empfohlene Einfügepunkt 
im Programm so aussieht: 


N einlesen 
DATA 0,-1,1,0,0,1,-1,0 
COLOR 2,0:G0SUB grafix 
"Grafik erzeugen 

CALL SetTaskPri(task&,0) 


newgame: 'Neues Spiel 
CLS 
FOR i-0 TO 15 


Nochmals ca. 10 Prozent 
kónnen Sie holen, wenn Sie die 
Kommentare entfernen oder 
auf das absolute Minimum kür- 
zen. Die Redaktion ist der Mei- 
nung, daß in diesem Fall Infor, 
mation und Programm-Doku- 


GOSUB kern * 
NEXT 
NEXT 


mentation vor Ablaufgeschwin- 
digkeit zu setzen sind und hat 
daher die Kommentare nicht 
ausgefiltert - wie wir glauben, 
auch in Ihrem Interesse. 

Um in den Genuß von 
»REAKTOR« zu kommen, müs- 
sen Sie einen von zwei mögli- 
chen Wegen beschreiten. Ent- 
weder Sie kopieren den Inhalt 
der Schublade »REAKTOR« 
von der Leserservice-Diskette 
auf Ihre Spiele-Diskette oder 
Sie tippen Listing 1 ab (der Auf- 
wand hált sich in Grenzen) und 
speichern das Programm auf 
Ihrer · Basic-Spiele-Diskette - 
fertig. Das Spiel starten Sie ent- 
weder durch Anklicken des 
Icons oder - aus dem CLI - mit 


run AmigaBASIC “Reaktor” 

Und nicht vergessen: recht- 
zeitig Freundin oder Freund 
zum Spielen einladen. Viel 
Spaß! so 


berechnen (Vergl. geben -1 wenn wahr !) 


LOCATE 1,18:COLOR 2,0:PRINT "REAKTOR (с) 1988 by T.Bagdonat” 


р1=1 


LOCATE 25,28:COLOR 2,0:PRINT "Kerne 


Neutronen” 


LOCATE 27,15:COLOR 11,0:PRINT "Player 17 'Bildschirmaufbau 
LOCATE 29,15:COLOR 8,0:PRINT "Player 2^"; 
ke(0)=0:ke(1)=0:ne(0)=0:ne(1)=0:GOSUB kene 


newplay: 


'Naechster Zug 
GOSUB kene:pl=ABS(pl-1) :add=p1*2-1 


"pl immer 0 oder -1 


COLOR ABS(pl-1)*348:LOCATE 10,64:PRINT "Р1ауег”;р1+1; 


SOUND р1%200%250,2,60,1 


LOCATE 14,64:COLOR 2,0:PRINT "Time"; "Timerbehandlung 


t=mt:COLOR 3,0:PRINT t 


warte: 


‘Jede Sekunde ein Sprung nach 
ON TIMER(1) GOSUB zeit:TIMER ON e 


' zeit 


MOUSE ON:ON MOUSE GOSUB click:flag=0 'Mausbehandlung initialisieren 


WHILE flag=0 AND t>0:WEND 
mx-MOUSE(1) :my=MOUSE(2) 
IF t-0 THEN newplay 


'flag s.click 
'Position des Mauszeigers 
'Wenn Zeit vorbei,dann weiter 


xx=INT( (mx-xoff) /60) :yy=INT((my+5-yoff) /30) 'Mauspos.in Kernpos. 


IF хх<0 OR xx>=xan OR уу<0 OR yy>=yan THEN warte 


v2=SCN(anz%(xx,yy)) 


'Ausserhalb ? 
'Wem gehoert Kern ? 


IF vz< >add AND у2< 20 THEN warte 'Nicht dem Spieler ? 


TIMER OFF 


'Timerbehandlung abschalten 


ne(pl)=ne(pl)+1:1F anz%(xx,yy)=0 THEN ke(pl)=ke(pl)+1 


anz%(xx,yy)=anz%(xx,yy)+add:aender=0:G0SUB kern 


vorne: 
GOSUB kene:ne=ne(0)+ne(1) 


'Neutron dazu 


'Hauptschleife fuer Kettenreaktion ! 


pl2-ABS(pl-1):IF Ке(р12)-0 AND пе>1 THEN GOTO sieg 'Gegner К.о. 


FOR ey=0 TO yan-1 
FOR ex=0 TO xan-1 


'Kern mit kritischer Masse suchen 


IF АВ5(ап2%(ех,еу)) <max%(ex,ey) THEN NEXT:NEXT:GOTO newplay 
xp=20+ex*60+xoff:yp=ey*30+yoff 'Gefunden und Pos. auf Bildschirm 


PUT (xp,yp),explf,PSET:GOSUB exso 
'vv ist Nr. des akt. Vektors 


vv=0:aa=max% (ex, ey) 
weiter3: 
xxsex+xv(vv) :уу=еу+уу (уу) 


'Explosionsgrafik anzeigen 


'Pos des zu besetzenden Kerns ber. 


IF хх<0 OR xx>=xan OR уу<0 OR yy» -yan THEN weiter2 'Ausserhalb- 


? 


aender=0:vz2=SGN(anz%(xx,yy)) 'Wem gehoert Kern ? 


IF у22< >у2 THEN 


'Wenn nicht dem Spieler, dann 


anz%(xx,yy)=-anz%(xx,yy):aender=1 'Kern-und Neutr. neu ber. 
ke(pl)=ke(pl)+1:ne(pl)=ne(pl)+ABS(anz%(xx,yy)) 
IF у22< >0 THEN Ке(р12)-Ке(р12)-1:пе(р12)-пе(р12)- 
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ABS (anz% (хх,уу)) 

END IF 

anz%(xx,yy)=anz%(xx,yy)+add:ne(pl)=ne(pl)+1 

GOSUB кегп "Kern zeichnen 
aa=aa-1:anz%(ex,ey)=anz%(ex,ey)-add 'Neutr.anz.alter Kern -1 
IF aa=0 THEN "Alle Neutr.verteilt ? 
хх-ех:уу-еу:005/В kern:ne(pl)=ne(pl)-max%(ex,ey) 
IF anz%(ex,ey)=0 THEN ke(pl)-ke(pl)-1 'Dann alten Kern zeichnen 
GOTO vorne 'Naechster Expl.durchlauf und Neutr. bzw.Kernzahl 
END IF 'neu berechnen 

weiter2: 
vv=vv+1:GOTO weiter3 'Naechsten Richtungsvektor bestimmen 
END 


grafix: ` ‘Grafik erzeugen 
FOR p=0 TO 2 'Drei Kernarten (0..2) 
gx=40:gy=20+pX30 "Pos. auf Bildschirm 
FOR m=1 70 40 "Jeder Kern 40 Nukleonen 
wiswi+.35:1=RND*10+1 "Winkel erhoehen und Radius waehlen 
x=gx+C0S(wi) #1 
yegy+SIN(wi)*(1/2):r=3 'Pos.auf Kreis mit zufaell.Radius 
cosINT(RND¥1.5+.5) 'Farbe zufaell.ermitteln 
IF p=2 THEN со=0 'p=2 ist neutraler Kern 
IF cosi THEN co=co+p "Sonst Farbe entsprechend p ber. 
GOSUB kugel 'Nukleon zeichnen 
NEXT 
GET (gx-22, gy-14)-(gx+22,gy+14) kernf(0,p) 'Orafik ausschneiden 
NEXT 
Ех-40:6у-110:Ға(1)-9:Ға(2)-8:Ға(2)-12 'Farben u.Pos. d. Ex.grafik 
FOR mm=1 TO 3 "Drei Ringe 
pls(3-mm)*442:mus (4-mm)*4 'max.und min. Radius 
fasfa(mm):wis0:axsgxemu:aysgy 'Zu verw. Farbe und Startpos. 
FOR m=1 TO 30 "30 Pos.auf Ring 
wiswi+.21 130х0.21-2рі (Einmal rum) 
nx=gx+C0S(wi)*(RND*mu+p1) 
ny=gy+SIN(wi)*((RND*mu+p1)/1.5) 'neue Pos.im Bereich pl..mu 
LINE (ах,ау)-(пх,пу),Ға:ах-пх:ау-пу 'alte+neue Pos. verbinden 
NEXT 
LINE (nx,ny)-(gx+mu,gy),fa 'Zurueck zum Anfang 
PAINT (gx,gy),fa 'Ring ausmalen 
NEXT 
GET (gx-22,gy-14)-(gx*22,gy*14),explf 'Expl.grafik ausschneiden 
RETURN 


kugel: 'Nukleon zeichnen 
fa=3*co+5:CIRCLE (x,y),3,fa "Echte Farbe ber.und Kreis 
PSET (x,y),fa:PSET(x-1,y),fa !5%а%% ausmalen mit Punkten 
PSET(x+1,y),fa:PSET (x-2,y),fa 'fuellen (schneller !!) 
CIRCLE (X,y),r,fa-1,.4Xpi,1.3*pi "Schattierung durch farbl. 
CIRCLE (x,y),r,fa41,1.5Xpi,.5*pi 'abgestufte Halbkreise 
RETURN 


kern: 'Kern zeichnen 
xp=20+xx*60+xoff:yp=yy*30+yoff 
ang=anz%(xx, yy) 


'Bildschirmpos.ber. 

"Anzahl der zus.Neutronen 
IF ABS(anz)>=2 AND aender=0 THEN rand 'Kern nicht neu zeichnen 
IF anz-0 THEN co=2:GOTO draw "Farbe aus VZ von. Neutr.anzahl 
IF anz>0 THEN co=0:ELSE cosi 

draw: 'Entspr.Kerngrafik auf Bild- 
PUT (xp,yp),kern%(0,co),PSET "'schirm bringen 


IF anz=0 THEN RETURN 'Keine zus. Neutronen,dann Ende 
rand: 'Zusaetzliche Neutr. zeichnen 
у=0:6х=хр+22:6у=ур+14:1=0 
again: 
xnexxexv(v) :уп=уу+уу(у) 'Pos.des Neutrons ber. 
IF хп<0 OR xn» =хап OR yn« 0 OR yn>=yan THEN weiter 'Ausserhalb ? 
ieiel:xegxexv(v)18:ysgyeyv(v)*9 "Bild.pos.ber. 
c0=0:G0SUB kugel 'Nukleon zeichnen 
weiter: 
v=v+1:IF isABS(anz) THEN RETURN:ELSE GOTO again 'Naechstes Neutr. 


click: 'Wird aufgerufen,wenn ein Maus- 
a-MOUSE(0):flage-1:MOUSE OFF 'ereignis stattfindet und 
RETURN 'signalisiert das durch flag 


Zeit: 
LOCATE 14,68:t=t-1:COLOR 3,0:PRINT t 'Wird jede Sekunde aufgerufen 
IF t<5 THEN SOUND 700,1,100,1 "und zaehlt die Zeit runter 
RETURN 


kene: "Schreibt die Anzahl der Kerne 
FOR 11-0 TO 1 'bzw.Neutr.auf den Screen 
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SPIELE 


COLOR 3,0:LOCATE 27+11*2,29:PRINT ke(11); 
LOCATE 27+11%2,38:РВІМТ ne(11); 
NEXT 
RETURN 


sieg: 'Wird am Spielende angesprungen 
LOCATE 27+p1*2,45:COLOR 2,0:PRINT “hat gewonnen 11”; 
co=p12*3+8 :a=MOUSE(0) 
weiters: қ 
FOR 1-5 TO 15 'Farblauf in Goldartigem 
PALETTE co,1/17,1/19,1/24 'Ton fuer Siegerfarbe rauf 
PALETTE co-1,1/15,1/17,1/22 
NEXT 
FOR 1215 TO 5 STEP -1 
PALETTE со,1/17,1/19,1/24 
PALETTE со-1,1/15,1/17,1/22 
NEXT 
IF MOUSE(0)-0 THEN weiter5 "Bis Mausbutton gedrueckt... 
GOTO newgame 'Dann neues Game 


'...und wieder runter 


exso: "Expl.sound 
WAVE 0,чау% "Rauschwelle setzen 
FOR i=0 TO 10 
PALETTE 0,1/15,1/17,0:PALETTE 1,1/15,1/17,0 'Hintergr aufleuchten 
SOUND INT(RND*20+10),.4,(10-1)*25 'Sound mit Zuf.freq 
NEXT 
PALETTE 0,0,0,0:PALETTE 1,0,0,0 "Hintergrund wieder schwarz 
RETURN 


Listing 1. »REAKTOR« - 
Kettenreaktion im Homecomputer 


SCREEN 1,640,250,4,2 
WINDOW 2,””,(0,0)-(631,230),0,1 
DIM kern£(600,2) ‚exp1%(600) 
grafix: 'Grafik erzeugen 
FOR p=0 TO 2 'Drei Kernarten (0..2) 
gx=40: gy=20+p*30 'Pos. auf Bildschirm 
FOR m=1 TO 40 'Jeder Kern 40 Nukleonen 
wi=wi+.35:1=RND*10+1 ‘Winkel erhoehen und Radius waehlen 
x=gx+00S(wi)*L 
y=gy+SIN(wi)*(1/2):r=3 'Pos.auf Kreis mit zufaell.Radius 
co=INT(RND*1.5+.5) "Farbe zufaell.ermitteln 
IF р=2 THEN со=0 'p=2 ist neutraler Kern 
IF co=1 THEN co=co+p "Sonst Farbe entsprechend p ber. 
GOSUB kugel 'Nukleon zeichnen 
NEXT 
GET (gx-22, gy-14)-(gx+22,gy+14) ,kern%(0,p) 'Orafik ausschn. 
NEXT 
gx=40:gy=110:fa(1)=9:fa(2)=8:fa(3)=13 'Farben+Pos.der Expl. 
FOR mm=1 TO 3 "Drei Ringe 
pl=(3-mm)*4+2:mu=(4-mm)%*4 'max.und min. Radius 
fa=fa(mm) :wi=0:ax=gx+mu:ay=gy 'Zu verw. Farbe und Startpos. 
FOR m=1 TO 30 "30 Pos.auf Ring 
мі=м1+.21 130х0.21-2рі (Einmal rum) 
nx=gx+C0S(wi)*(RND*mu+p1) 
ny=gy+SIN(wi)*((RND¥mu+p1)/1.5) 'neue Pos.im Bereich pl..mu 
LINE (ax,ay)-(nx,ny),fa:exenx:aysny 'alte+neue Pos. verb. 
NEXT 
LINE (nx,ny)-(gx+mu,gy),fa 'Zurueck zum Anfang 
PAINT (gx,gy),fa 'Ring ausmalen 
NEXT 
GET (gx-22,gy-14)-(gx+22,gy+14) ‚exp1% 'Expl.grafik ausschneiden 
END 


kugel: 'Nukleon zeichnen 
fa=3*co+5:CIRCLE (x,y),3,fa "Echte Farbe ber.und Kreis 
PSET (x,y),fa:PSET(x-1,y),fa 'Statt ausmalen mit Punkten 
PSET(x+1,y),fa:PSET (x-2,y),fa 'fuellen (schneller !!) 
CIRCLE (x,y),r,fa-1,.4*pi,1.3*pi 'Schattierung durch farbl. 
CIRCLE (x,y),r,fa*1,1.5*pi,.5*pi 'abgestufte Halbkreise 
RETURN 


Listing 2. 
REAKTOR.graph - das Prinzip der Kern-Grafik 


Von Fridtjof Siebert 
und Martin Jobst 


rafik ist ein Markenzei- 
chen des Amiga. Jede 
Menge toller Program- 


me lassen das Thema zur Fas- 
zination werden. Doch wie kön- 
nen Sie Ihre mit DPaint & Co. 
gemalten Werke in das eigene 
Spiel einbauen? Fridtjof Sie- 
bert, Programmierer des Amok- 
Klubs aus Stuttgart, zeigt Ih- 
nen, wie Sie Ihre Programme 
optisch aufwerten. Dabei unter- 
stützen Sie die von »IFFSup- 
port« (Listing 1) exportierten 
Prozeduren. Damit können Sie 


IFF-Bilder laden, speichern 
und auch Farbanimationen zei- 
gen. 


Anders als bei gängigen IFF- 
Unterstützungsroutinen üblich, 
werden bei »IFFSupport« die 
geladenen Daten in bekannten 
Formaten (Screens, Windows 
und BitMaps) übergeben und 
nicht so, wie sie im IFF-File vor- 
liegen. Dadurch wird die Hand- 
habung wesentlich vereinfacht 
(siehe unten). 

Wir stellen hier die neueste 
Version der Routine vor, welche 
Sie auf der AMOK 21 finden. 
Sie kann mit »M2Amiga V3.2« 
compiliert werden. Neben Ver- 
besserungen wurden auch eini- 
ge Fehler gegenüber der alten 
Version von der AMOK-Diskette 
Nr. 6 behoben. 

Die Prozeduren lassen sich 
nur in Modula-Bibliotheken ein- 
bauen. Im Beitrag auf Seite 30 
finden Sie Tips, wie Modula- in 
C-Programme konvertiert wer- 
den können. Listing 2 zeigt das 
Definitionsmodul »IFFSupport. 
def«. Eine Beschreibung der 
Variablen und Typen finden Sie 
in nebenstehender Tabelle. In 
Listing 6 finden Sie die Defini- 
tion der Maschinenroutine »Lo- 
adBody.def«, Listing 7 ist deren 
Definition. 


Laden von 
IFF-Bildern 


Mit der Prozedur 


PROCEDURE ReadILBM 
(name: ARRAY OF CHAR; 
Flags: ReadILBMFlagSet; 
VAR Screen: ScreenPtr; 
VAR Window: WindowPtr): 
BOOLEAN; 

laden Sie ein IFF-Bild mit dem 

Namen »name«. Tritt ein Fehler 

auf, wird »FALSE« zurückgege- 

ben. Folgende Flags wählen 

Sie aus der Menge »Read- 

ILBMFlagSet«: 

- front: ist »front« gesetzt, wird 

der Screen, in den die Grafik 
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geladen wird, vor allen anderen 
Screens geöffnet, sonst dahinter 
- visible: ist »visible« nicht ge- 
setzt, wird während dem Laden 
das Display mit »GfxMacros. 
OffDisplay()« abgeschaltet. Das 
erhöht die Ladegeschwindig- 
keit, besonders bei Bildern mit 
hoher Auflösung und/oder vie- 
len Farben. 
- dontopen: wenn gesetzt, wird 
kein Screen geöffnet. Der zu- 
rückgegebene »ScreenPtr« 
wird dann »NIL:«. Die Grafik 
wird in eine Bitmap geladen, 
wobei der Zeiger auf diese in 
»IFFSupport.NuScreen.cu- 
stomBitMap« steht. Der Screen 
kann spáter mit »OpenScreen« 
geóffnet werden. Bei gewáhl- 
tem »dontopen« muß der Spei- 
cher für die Bitplanes und die 
Bitmap-Struktur spáter wieder 
freigegeben werden. 
- window: wenn gesetzt, wird 
vor dem Laden der Grafikdaten 
in den Screen ein Fenster mit 
der Größe der Grafik geöffnet. 
Dadurch können später Gad- 
gets, Menüs etc. hinzugefügt 
werden, ohne die Grafik zu zer- 
stören. Wenn »window« ge- 
löscht ist, wird der »WindowPtr« 
zu »NIL:«. 


Pixelpracht I 


Spiele auf dem Amiga leben von ih 
Einbindung von Bilderni 


Die Laderoutine unterstützt 
alle Auflósungen: Lores, Hires, 
Interlace, Hold and Modify 
(HAM) und Extra Half-Brite. Ge- 
packte Bilder werden entspre- 
chend entpackt. Da der Ent- 
packer in Maschinensprache 
geschrieben ist, stehen ge- 
packte Bilder am Ende schnel- 
ler im Speicher als ungepackte. 

Mit »DoCycle« kann das Co- 
lor-Cycling für eine Grafik ein- 
geschaltet werden: 
PROCEDURE DoCycle 

(Info: IFFInfoTypePtr; 

Sereen: SereenPtr): 
BOOLEAN; 


PROCEDURE EndCycle 
(Info: IFFInfoTypePtr); 
Color-Cycling, oder Farbani- 


Variablen & Typen 


Von IFFSupport werden folgende Variablen und Typen exportiert: 


TYPE 


IFFInfoTypePtr = POINTER TO IFFInfoType; 


IFFInfoType - RECORD 
.. (x Mega-Record x) 
END; 
“УАН 


IFFInfo: IFFInfoType; 


»IFFInfo« enthält Informationen über das zuletzt geladene Bild oder 
über ein zu speicherndes Bild. Wenn mehrere Bilder verwendet wer- 
den, müssen eigene Variablen vom Typ »IFFinfolype« definiert wer- 
den, da bei jedem neuen Laden »IFFinfo« überschrieben wird. 


VAR 
NuSereen: NewSereen; 
NuWindow: NewWindow; 


Diese kónnen importiert werden, um spáter einen Screen mit der 
Grafik oder ein Window in diesem Screen zu öffnen (siehe auch 
»ReadILBM();«). 


TYPE 


IFFErrors = (iffNoErr, iffOutofMem, iffOpenScreenfailed, 
iffOpenWindowfailed, iffOpenfailed,iffWrongIFF, 


iffReadWritefailed) ; 
VAR 
IFFError: IFFErrors; 


»IFFErrors« enthält die Fehlerart, wenn das eee oder Speichern 


eines Bildes erfolglos war. 
iffNoErr: 
iffOutofMem: 
iffOpenScreenfailed: 
iffOpenWindowfailed: 
iffOpenfailed: 
iffWronglFF: 
iffReadWritefailed: 


kein Fehler 

nicht genügend Speicher 
»OpenScreen« ist fehlgeschlagen 

es konnte kein Fenster geöffnet werden 
File konnte nicht geöffnet werden 

kein IFF-File 

Schreib-/Lesefehler 


mation heißt, die Farben eines 
Bildes beginnen zu rotieren, 
wechseln zyklisch. Dazu wird 
ein »VBlank«-Interrupt initiali- 
siert, das Cycling läuft also im 
Hintergrund Ihres Programms. 
»DoCycle« benötigt einen 
»ScreenPtr« und die Adresse 
einer »IFFInfolype«-Variablen. 
Werden gleichzeitig mehrere 
Bilder mit Color-Cycling ge- 
zeigt, müssen auch verschie- 
dene Variablen verwendet wer- 
den. »DoCycle()« gibt »FALSE« 
zurück, wenn ein Fehler auftritt. 
Ein solcher kommt dann zu- 
stande, wenn mehr als 32 Co- 
lorCycling-Bilder gleichzeitig 
eingeschaltet sind. Da dies ge- 
wöhnlich nicht der Fall ist, kann 
»DoCycle« mit 
IF DoCycle(ADR(IFFInfo) , 
Screen) THEN END; 


aufgerufen werden. 


Als die Farben 
laufen lernten 


»EndCycle()« beendet das 
Color-Cycling. Dazu überge- 
ben Sie den gleichen »IFFInfo- 
TypePtr« wie bei »DoCycle«. 
»EndCycle« sollten Sie nicht 
vergessen, da ansonsten die 
Interrupts von »IFFSupport« 
nicht entfernt werden. Also muß 
»EndCycle« spätestens in der 
»TermProcedure«, kurz vor dem 
Schließen des Screens, aufge- 
rufen werden! 

Zum Speichern von IFF-Bil- 
dern sind drei ähnliche Proze- 
duren vorhanden: 

PROCEDURE 

WriteILBM Screen 

(Name: ARRAY OF CHAR; 

Screen: ScreenPtr; 

Rect: RectanglePtr; 

CompressIt: BOOLEAN): 

BOOLEAN; 


speichert den Screen unter 
»Name«. Trat ein Fehler (»iffO- 
penfailed« oder »iffReadWrite-. 
failed«) auf, wird »FALSE« zu- 
rückgegeben. Wenn »Com- 
presslt« auf »TRUE« ist, wird ein 
gepacktes File erzeugt. »Rect« 
kann »NIL« sein, wenn der gan- 
ze Screen gespeichert werden 
soll. Sonst enthált es einen Zei- 
ger auf ein »Graphics.Rectan- 
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Viodula-Programme 


ichtgemacht 


gle« — »Rect.minX/minY« ist 

dann die linke obere und 

»Rect.maxX/maxY« die rechte 

untere Ecke des Ausschnitts. 

Dabei sollte man Ausschnitte, 

die gróBer als der Screen sind, 

vermeiden. 

PROCEDURE WritelLBM 
(Name: 

ARRAY OF CHAR; 

RP: RastPortPtr; 
VP: ViewPortPtr; 
Rect: RectanglePtr; 
CompressIt: 
BOOLEAN): BOOLEAN; 

Speichert wie »WritelLBMSc- 
reen« ein IFF-File. »Name«, 
»Rect«, »Compresslt« und der 
»RETURN«-Wert entsprechen 
dieser Prozedur. »RP« zeigt auf 
den »RastPort«, der die Grafik- 
daten enthält. »VP« weist auf ei- 
nen »ViewPort«. Dieser enthält 
die Farben und »ViewModes« 
etc. 

Mit »WritelLBM« speichern 
Sie ein Fenster folgenderma- 
Ben (das Fenster muß dabei vor 
allen anderen liegen): . 

VAR 3 
Window:Intuition. 
WindowPtr; 
Rect:Graphics. 


:Programm. 
:Autor. 
Adresse. 
:Telefon. 
:Shorteut. 
Version. 
:Copyright. 
:Sprache. 
:Compiler. 
:Imports. 
:History. 
:History. 


IFFSupport.mod 
Fridtjof Siebert 


[fbs] 
1.5 
Modula-II 


M2Amiga v3.2 
LoadBody.asm [fbs] 


:History. 


:History. 
:History. 


V1.1 [fbs] 27-Jul-88: 
V1.2 [fbs] 16-Nov-88: 


V1.3 [fbs] 28-Dec-88: 


V1.4 [fbs] 23-Mar-89: 
V1.5 [fbs] 03-Jun-89: 


Grafik. »IFFSupport« hilft bei der 
hre eigenen Programme. 


Rectangle; 
OK: BOOLEAN; 


BEGIN 
WITH 
WITH 
minX: 
minY 
maxX: 
maxY: 
END; 
Error := WriteILBM 
(Name, rPort, 
ADR(wScreen‘.viewPort), 
ADR(Rect) , TRUE) ; 

END; 


Window DO 

Rect DO 

-leftEdge; 

opEdge; 

-minX + width -1; 
-minY + height -1; 


Die dritte Prozedur, »Write- 
ILBMAIl«, kann auch Bilder mit 
Zusatzinformationen wie Color- 
Cycling etc. speichern. 
PROCEDURE InitIFFInfo 

(Info: 
IFFInfoTypePtr; 

RP: RastPortPtr; 
VP: ViewPortPtr; 
VAR Rect: Rectangle 
Ptr); 


PROCEDURE WriteILBMAll 
(Name: 


Nobileweg 67, D-7000-Stuttgart-40 


Markt & Technik Verlag AG 


Erste veroeffentlichte Version 
Fehlerkorrektur 
(NIL-RectanglePtr) 

kleine Aenderungen, angeregt 
von S. Salewski 
Fehlerkorrektur (ExtraHB) 
Anpassung fuer v3.2, Fehler- 
korrektur (Add/RemInt- 
Server()-Bug (3.2)) 


PROCEDUREn für IFF-Bilder (Load, Save, 


ColorCycling). 
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ARRAY OF CHAR; 

Info: IFFInfoTypePtr; 
BM: BitMapPtr; 
FirstLine, LeftOffset: 
INTEGER; 

CompressIt: BOOLEAN) : 
BOOLEAN; 


Dazu wird die Adresse einer 
vorher initialisierten »IFFInfoTy- 
pe«-Variablen benótigt. Um die 
Initialisierung zu erleichtern, 
kann die Prozedur »InitIFFin- 
fo()« aufgerufen werden. Ihre 
Parameter entsprechen denen 
von »WritelLBM«. Danach sind 
die Subrecords »BMDH«, 
»CMAP« und »CAMG« initiali- 
siert und deren Flags in »In- 
fo‘.IFFTitle« gesetzt. Weitere 
können »per Hand« bearbeitet 
werden. 

»BM« zeigt auf jene Bitmap, 
welche die zu speichernden 
Planes enthält. Dabei kann 
»BM« auch zum Speichern neu 
initialisiert werden, etwa dann, 
wenn man eine zusätzliche 
»MaskPlane« speichern möch- 
te. »FirstLine« und »LeftOffset« 
entsprechen »Rect‘.minY« und 
»Rect.minX«. »Compressit« 
und der »RETURN«-Wert ver- 
halten sich analog zu »Write- 
ILBMScreen«. 


Abschließend stellen wir Ih- 
nen noch einige Beispiele für 
die Anwendung der Prozedu- 
ren vor. Das Programm »Show- 
IFF« (Listing 3) lädt und zeigt 
IFF-Bilder. Es lädt das zusam- 
men mit <SHIFT> vorher auf 
der Workbench angeklickte 
oder - beim Starten vom CLI 


IMPLEMENTATION MODULE IFFSupport; 


FROM SYSTEM 


FF 


aus - das angegebene Bild. Bil- 
der, die »ShowlFF« als Default- 
Tool haben (wird mit Workbench- 
Info bestimmt), kónnen durch 
einfachen Doppelklick ange- 
zeigt werden. An diesem kur- 
zen Programm können Sie die 
Verwendung der Ladeprozedur 
studieren. 

»ShowCycle« (Listing 4) stellt 
das »ShowlFF« für Color-Cyc- 
ling-Bilder dar. Normalerweise 
kann es auch für Bilder ohne 
Farbanimation verwendet wer- 
den, wenn die entsprechenden 
Informationen korrekt ausge- 
schaltet sind. 

Mit »ShowOVSC« (Listing 5) 
werden Color-Cycling-Bilder im 
Overscan-Format, also bild- 
schirmfüllend angezeigt. Bilder, 
die kleiner als die aktuelle 
Workbenchgröße sind, werden 
zentriert dargestellt. Dies sieht 
besonders bei NTSC-Bildern 
auf PAL-Amigas besser aus. 
Umgekehrt werden auf NTSC- 
Rechnern PAL-Bilder wie Over- 
scan-Bilder angezeigt. Dieser: 
Modus wurde aber noch nicht 
getestet. 

Die Beispiele sollen Ihnen 
die Anwendung der Prozedu- 
ren von »IFFSupport« zeigen, 
Sie aber auch zur Programmie- 
rung eigener Module anregen. 
Verhelfen Sie damit Ihren Spie- 
len zur wohlverdienten Pixel- 
pracht. so 


Martin Jobst studiert Publizistik und Kommuni- 
kationswissenschaft in Salzburg und arbeitet 
seit drei Jahren als freier Mitarbeiter für Zeit- 
schriften des Markt&Technik Verlages. Sie 
können ihn erreichen über unsere Verlagsan- 
schrift (Markt & Technik Verlag AG, Redaktion 
Sonderhefte, z. Hd. Martin Jobst, Hans-Pinsel- 
Straße 2, 8013 Haar bei München). 


IMPORT ADR, ADDRESS, SHIFT, BITSET, LONGSET, CAST, 


INLINE, REG, SETREG; 


FROM Arts 


FROM Exec 


IMPORT TermProcedure, Assert, BreakPoint; 


IMPORT AllocMem, FreeMem, MemReqs, MemReqSet, UByte, 


Interrupt, AddIntServer, RemIntServer, NodeType; 


FROM Dos 


IMPORT FileHandlePtr, Open, Close, Read, oldFile, 


Write, DeleteFile, Seek, newFile, beginning; 
FROM Intuition IMPORT NewScreen, ScreenPtr, OpenScreen, CloseScreen, 
бегеепТоВаск, ScreenFlags, ScreenFlagSet, 
eustomSereen, MoveScreen, WindowPtr, OpenWindow, 
CloseWindow, IDCMPFlags, IDCMPFlagSet, 
WindowFlagSet, WindowFlags; 
FROM Graphics IMPORT SetRGB4, RastPortPtr, BitMapPtr, ViewModes, 


ViewModeSet, 


BitMap, InitBitMap, AllocRaster, 


BltClear, FreeRaster, ViewPortPtr, 
RectanglePtr, Rectangle, GetRGB4; 
FROM GfxMacros IMPORT OffDisplay, OnDisplay; 


FROM Hardware IMPORT vertb; 
FROM Strings 


FROM LoadBody IMPORT LoadBody; 


IMPORT Compare, first, last; 


Listing 1. Der Quellcode von »IFFSupport« in Modula » 
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CONST 
MOVEMS = 48E7H; (* 68000-Instruction MOVEM to save Regs*) 
MOVEML = ACDFH; (* MOVEM to load Registers ж) 


ТҮРЕ P 
CyelingInfo = RECORD (% Needed Data for Cycle-Interrupt X) 
int: Interrupt; (* The Cycling's Interrupt ж) 
ҮР: ViewPortPtr; (* Тһе Oyeling's ViewPort ж) 
count: ARRAY[O..15] OF CARDINAL; (% Cyeling-Positions 
speedCnt: ARRAY[0..15] ОҒ CARDINAL; (* counts Speed 
END; 


VAR 
InH, OutH: FileHandlePtr; (* Files 
i,j,k: LONGINT; can be used by everything 
LineLength: LONGINT; Bytes per Image-Line 
LineWidth: LONGINT; Bytes per Screen-Line 
BM: BitMapPtr; Sereen's BitMap 
Compression: BOOLEAN; compressed ? *) 
MaskPlane: BOOLEAN; Is there a Mask-Plane ?? 
Buffer: ADDRESS; Buffer for Reading/Writing *) 
TextBuffer: POINTER TO ARRAY[0..63] OF ARRAY[O..3] OF CHAR; 
LONGBuffer: POINTER TO ARRAY[O..63] OF LONGCARD; 
WORDBuffer: POINTER TO ARRAY[0..127] OF INTEGER; 
BYTEBuffer: POINTER TO ARRAY[0..255] OF UByte; 
len: LONGINT; (* Length from Read/Write() X) 
BitMaps: ARRAY[O..7] OF ADDRESS; (* Pointer to Planes x) 
Line,Plane: LONGINT; (* Count Lines and Planes ж) 
Location,Right: POINTER TO UByte;(* Used loading Buffer *) 
RQPos,RQLen: LONOCARD; (ж Used by QuickRead-Procedure %) 
RQBuffer: POINTER TO ARRAY[0..511] OF UByte; (* ReadQu-Buffer *) 
Exit: BOOLEAN; (* Exit LOOP ? 
CycleInfos: ARRAY[O..31] OF CyclingInfo;(* Coloreyelings 
IntInfo: IFFInfoTypePtr; (* Interrupt's IFFInfo 
IntNum: CARDINAL; (* Interrupt's ID 
IntCount, IntCount2,IntCount3: CARDINAL; (* used for Cycling 
ColorConv: LONGCARD; (* converting Colors 
Address: ADDRESS; 
FileLength,BodyPos,BodyLength: LONGINT; (* Pos«Length in File *) 
ShiftBuffer: ARRAY[O..31] OF LONGSET; (XBuffer f Graphic-Shift*) 
ShiftSource: POINTER TO ARRAY[O..31] OF LONGSET; (* Points into 
Planes X) 


NeedToShift: BOOLEAN; (* is shifting really needed?*) 


ShiftWidth,BitsToShift: CARDINAL;(* how far+how many BitsToShift X) 


TrueLeftOffset,TrueWidtn: INTEGER; (* Word-aligned Offset & 
Width X) 


(*----- Procedure called by machinecpde to get Data: 
PROCEDURE Read512(); 


BEGIN 
len := Read(InH,RQBuffer, 512); 
END Read512; 


Wi 

TYPE 
ReadILBMFlags = 
ReadILBMFlagSet 


*) 


(front, visible, dontopen, window) ; 
= SET OF ReadILBMFlags; 


PROCEDURE ReadILBM(name: ARRAY OF CHAR; Flags: ReadILBMFlagSet; 
VAR Sereen: SereenPtr; 
VAR Window: WindowPtr): BOOLEAN; 


PROCEDURE OpenSern(); 


BEGIN 
WITH NuSereen DO H 
width := IFFInfo.BMHD.sernWidth; 
IF width« IFFInfo.BMHD.width THEN 
width :- IFFInfo.BMHD.width; 
END; 
height := IFFInfo.BMHD.scrnHeight; 
IF height <IFFInfo.BMHD.height THEN 
height :- IFFInfo.BMHD.height; 
END; 
leftEdge :- IFFInfo.BMHD.left; 
topEdge := IFFInfo.BMHD.top; 
depth := IFFInfo.BMHD.depth; 
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viewModes ViewModeSet[] ; 
IF (width>400) AND (depth<5) THEN INCL(viewModes,hires) END; 
IF height? 300 THEN INCL(viewModes,lace) END; 
WITH IFFInfo.CAMG DO 
IF (Lace IN viewType) THEN INCL(viewModes,lace ) END; 
IF (HoMod IN viewType) THEN INCL(viewModes,ham ) END; 
IF (Hires IN viewType) THEN INCL(viewModes,hires ) END; 
IF (Db1PF IN viewType) THEN INCL(viewModes,dualpf) END; 
IF (Extra IN viewType) THEN viewModes :- ViewModeSet[extra- 
Halfbrite] END; 
END; 
detailPen := 0; blockPen := 0; 
type := customScreentScreenFlagSet{ screenQuiet} ; 
font := NIL; 
defaultTitle := NIL; 
gadgets := NIL; 
customBitMap := NIL; 
IF NOT(front IN Flags) THEN topEdge := 600° END; 
END; 4 
IF dontopen IN Flags THEN 
INCL(NuScreen. type, customBitMap) ; 
WITH NuScreen DO 
customBitMap := AllocMem(SIZE(BitMap) ,MemReqSet{ public} ) ; 
InitBitMap(customBitMap ,depth,width, height) ; 
1:20; 
REPEAT 
customBitMap.planes[1] := AMocRaster(width,height);. 
BitMaps[1] := eustomBitMap.planes[1]; . ` 
IF BitMaps[1]-NIL THEN : 
IFFError := iffOutofMem; 
ELSE 
BltClear(BitMaps[i],width DIV 8 * height,0); 
END; 
INC(1); 
UNTIL (isdepth) OR (IFFError#iffNoErr); 
IF IFFError#iffNoErr THEN (% error: give Mem back: X) 
WHILE i>1 DO 
DEC(1); 
FreeRaster(BitMaps[1],width,heignt); 


Screen := OpenScreen(NuScreen) ; 
IF Screen=NIL THEN 
IFFError := iffOpenScreenfailed; 
ELSE 
IF NOT(front IN Flags) THEN 
SereenToBack(Screen) ; 
MoveScreen(Screen,0,-600) ; 
END; 
BM := Screen .rastPort.bitMap; 
FOR 1:20 TO NuScreen.depth-1 DO 
BitMaps[1] := BM.planes[1]; 
END; 
WITH IFFInfo.CMAP DO 
FOR 1:=0 TO colorCnt-1 DO 
SetRGB4(ADR(Screen’.viewPort) ,1,red[1),green[1],b1ue[1]); 
END; 
END; 
END; 
END; 
WITH NuWindow DO 
leftEdge := 0; 
topEdge := 0; 
width := IFFInfo.BMHD.width; 
height := IFFInfo.BMHD.height; 
detailPen :- 1; 
blockPen := 0; 
idempFlags := IDCMPFlagSet{} ; 
flags := WindowFlagSet[borderless,noCareRefresh) ; 
firstGadget NIL; 
checkMark := NIL; 
title := NIL; 
screen Screen; 
bitMap NIL; 
type := customSereen; 
END; 
IF (window IN Flags) AND (Screen#NIL) THEN 
Window := OpenWindow(NuWindow); 
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IF Window=NIL THEN 
CloseSereen(Screen); 
Screen := NIL; 
| IFFError := iffOpenWindowfailed; 
END; 
END; 
IF NOT(visible IN Flags) THEN OffDisplay() END; 
END OpenSern; 


PROCEDURE ReadQuick(To: ADDRESS; Count: CARDINAL); 


VAR 
ToPtr: POINTER TO ARRAY[0..9999] OF UByte; 
1: CARDINAL; 


BEGIN 
ToPtr := To; 
1:20; 
REPEAT 
IF RQPos-RQLen THEN 
RQLen := Read(InH,RQBuffer,512); 
RQPos := 0; 
END; 
ToPtr [i] := RQBuffer [RQPos]; 
INC(RQPos); INC(1); 
UNTIL i=Count; 
END ReadQuick; 


BEGIN ^ 
IFFInfo.IFFTitle := IFFTitleSet[]; 


. IF NOT(visible IN Flags) THEN OffDisplay() END; 
IFFError := iffNoErr; 
Screen NIL; Window := NIL; 
RQPos RQLen := 0; 


ТАН := Open(ADR(name) ,oldFile) ; 


IF InH=NIL THEN 
IFFError := iffOpenfailed; 


File Header: ------*) 


len := Read(InH,Buffer,12); 


FF 


ELSIF Compare(TextBuffer'[0],first,4,"CMAP",TRUE)-O THEN 
INCL(IFFInfo. IFFTitle, CMAP) ; 
len := Read(InH,Buffer,4) ; 
i := LONGBuffer [0]; 
len := Read(InH,Buffer,1); 
WITH IFFInfo.CMAP DO 
colorCnt : 1 DIV 3; 
J := 0; 
FOR k:-0 TO colorCnt-1 DO 
red [k] := BYTEBuffer[] 1 DIV 16; 
green[k] := BYTEBuffer[j41] DIV 16; 
blue [k] := BYTEBuffer[)42) DIV 16; 
Ікс(),3); 


ELSIF Conpare(TextBuffer'[0],first,4, "CAMG”,TRUE)=0 THEN 
INCL(IFFInfo.IFFTitle,CAMG); 
len := Read(InH,Buffer,8); 
IFFInfo.CAMG.viewType := CAST(ViewTypeSet,LONGBuffer'[1]); 


m] 


ELSIF Compare(TextBuffer'[0),first,4, "GRAB”,TRUE)=0 THEN 
INCL(IFFInfo.IFFTitle,ORAB); 
len := Read(InH,Buffer,8); 
IFFInfo.GRAB.hotX := WORDBuffer [2]; 
IFFInfo.GRAB.hotY := WORDBuffer [3]; 


(%------ DEST: 


ELSIF Compare(TextBuffer [0],first,4,"DEST",TRUE)-0 THEN 
INCL(IFFInfo.IFFTitle,DEST) ; 
len := Read(InH,Buffer,12); 
WITH IFFInfo.DEST DO 
depth іш BYTEBuffer [4]; 
planePick := WORDBuffer [3]; 
planeOnOff := WORDBuffer [4]; 
planeMask := WORDBuffer (51; 


IF len#12 THEN IFFError := iffReadWritefailed END; 
IF (Compare(TextBuffer [0] ,first,4, "FORM",TRUE) #0) OR ELSIF Compare(TextBuffer [0], first,4, "CRNG”,TRUE)=0 THEN 
(Compare(TextBuffer [2], first,4, "ILBM”, TRUE) #0) THEN IF NOT(CRNG IN IFFInfo.IFFTitle) THEN 
IFFError := iffWrongIFF; IFFInfo.CRNG.count := 0; 
END; ` ` END; 
INCL(IFFInfo.IFFTitle,CRNG); 
Exit := FALSE; len := Read(InH,Buffer,12); 
$ WITH IFFInfo.CRNG.data[IFFInfo.CRNG.count] DO 
- Main Loop: - -%) rate := WORDBuffer'[3]; 
on := 0 IN CAST(BITSET  WORDBuffer'[4]) ; 
WHILE (IFFError=iffNoErr) AND NOT(Exit) DO forward := NOT(1 IN CAST(BITSET,WORDBuffer'[4])) ; 
len := Read(InH,Buffer,4); low := BYTEBuffer [10]; 
high := BYTEBuffer [11]; 
- BMHD: ------*) (* this line is only to identify illegal data, that some IFF- 
Files contain:*) 
IF Compare(TextBuffer'[0),first,4, "BMHD”,TRUE)=0 THEN on : on AND (low<IFFInfo.CMAP.colorCnt) 
INCL(IFFInfo.IFFTitle,BMHD); AND (high< IFFInfo.CMAP.colorCnt) ; 
len := Read(InH,Buffer,4) ; END; 
len := Read(InH,Buffer,LONGBuffer (01); INC(IFFInfo.CRNG.count) ; 
WITH IFFInfo.BMHD DO 
width 
height 
left WORDBuffer [2]; ELSIF Compare(TextBuffer [0],first,4, "BODY”,TRUE)=0 THEN 
top WORDBuf fer (3. INCL(IFFInfo. IFFTitle , BODY) ; 
depth := BYTEBuffer [8 OpenSern(); 
masking BYTEBuffer'[9]; IF IFFError=iffNoErr THEN 
MaskPlane := masking=1; len :- Read(InH,Buffer,4); 
Compression :- BYTEBuffer' [10]-1; LineLength := CAST(INTEGER, CAST(BITSET, IFFInfo.BMHD.width+ 
transCol WORDBuffer [6]; 15) 
xAspect := BYTEBuffer (141; * [4..15]) DIV 8; 
yAspect := BYTEBuffer (151; LineWidth := CAST( INTEGER, CAST(BITSET,NuScreen.width+15) 
sernWidth := WORDBuffer [8]; * [4..15]) DIV 8; 
sernHeight:- WORDBuffer (91; 


Listing 1. (Fortsetzung) 


AMIGA-SONDERHEFT 7 1 1 3 


IF Compression THEN 
let's load the BitMap's Data: 

LoadBody(Read512, RQBuffer, ADR(BitMaps[0]), LineLength, 
LineWidth, IFFInfo.BMHD.height, NuScreen.depth, 
MaskPlane); (* this does all the work very 
quickly *) 

ELSE (% not compressed %) 
(%------ to load uncompressed Images is less time- 
critical: *) 

FOR Line := 0 TO IFFInfo.BMHD.height-1 DO 

FOR Plane := 0 TO NuScreen.depth-1 DO 


ReadQuick(BitMaps[Plane]+ LineWidth*Line, LineLength) ; 


END; 
IF MaskPlane THEN 
ReadQuick(Buffer, LineLength) ; 


END; (* IF NoErr *) 
Exit := TRUE; 


(*------ Ignore unknown data: ------%) 


ELSE 
len := Read(InH,Buffer,4); 
1 := LONGBuffer [0]; 
WHILE 12256 DO 
len := Read(InH,Buffer,256); 
DEC(1,256); 
END; 
len :- Read(InH,Buffer,1); 
END; 


(*------ Detect ReadError: ------*) 


IF 1еп=0 THEN 
IFFError := iffReadWritefailed; 
END; 


END; (* WHILE NOT(Exit DO *) 
END;  (* IF NoErr ai 


IF InH#NIL THEN Close(InH); InH := NIL; END; 
IF IFFError#iffNoErr THEN 
IF Windows*NIL THEN CloseWindow(Window) END; 
IF Screen#NIL THEN CloseScreen(Screen) END; 
END; 
OnDisplay(); 
RETURN IFFError=iffNoErr; 
END ReadILBM; (* that's it *) 


(*--------- Procedures for ColorCyoling: ----------- -----%) 
PROCEDURE CycleInterrupt(); 


BEGIN 
INLINE(MOVEMS, 3F3EH) ; 


IntInfo := ADDRESS(REG(9)); 
IF CRNG IN IntInfo .IFFTitle THEN 
IntNum := IntInfo.Internal.CycleID; 
WITH CyeleInfos[IntNum] DO 
IntCount := 0; 
WHILE IntCount < IntInfo .CRNG.count DO 
WITH IntInfo’.CRNG.data[IntCount] DO 
IF on THEN 
INC(speedCnt[IntCount] , rate); 
IF speedCnt[IntCount] > =4000Н THEN 
(* this 4000H should be 8000H, but that's to slow. *) 
(* dont know why, but this way, it works correctly *) 
DEC(speedCnt[IntCount],4000H); 
IF forward THEN 
IF count[IntCount] <=low THEN 
count[IntCount]:shigh; 
ELSE 
DEC(count[IntCount]) ; 
END; 
ELSE 
IF count[IntCount]>=high THEN 
count[IntCount]:=low; 
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ELSE 
INC(count[IntCount]) ; 
END; 
END; 
IntCount3 := count[IntCount]; 
IntCount2 := low; 
WHILE IntCount2« -high DO 
SetRGB4(VP, IntCount2, IntInfo .CMAP. red[IntCount3], 
IntInfo .CMAP.green[IntCount3], 
IntInfo .CMAP.blue[IntCount2]); 


INC(IntCount3); 
IF IntCount3>high THEN IntCount3:=low END; 
INC(IntCount2) ; 


INLINE(MOVEML, 7CFCH) ; 
END CycleInterrupt; 


PROCEDURE DoCycle(Info: IFFInfoTypePtr; Screen: ScreenPtr): BOOLEAN; 
(* this creates an interrupt, that does cycling. You needn't worry,*) 
(* whether there's cycling data or not. Don't forget to call EndCycle 
to si 

(* remove the Cycling-Interrupt !!! x) 


(* If result is false, any error occured. Don't call EndCycle in 
this саве!%) 


BEGIN 


100Р 
IF CyeleInfos[i].VP=NIL THEN EXIT END; 
INC(1); 
IF 1232 THEN RETURN FALSE END; 
END; : 
Info’.Internal.CycleID := i; 
WITH CycleInfos[1) DO 
VP := ADR(Sereem.viewPort); 
IF САМО IN Info .IFFTitle THEN 
FOR ):-0 TO Info .CRNG.count-1 DO 
count(J] := Info'.CRNG.data[J].10v; 
SpeedOnt[]] := 0; 
END; 
END; 
WITH int DO 
node.type :- interrupt; 
node.pri := -60; 
node.name NIL; 
data := Info; 
code := ADR(CycleInterrupt) ; 
END; 
SETREG(0,0); AddIntServer(vertb,ADR(int)); 
END; ` 
RETURN TRUE; 
END DoCycle; 


PROCEDURE EndCycle(Info: IFFInfoTypePtr); 
(* remove cycling-Interrupt 


BEGIN 
i := Info.Internal.CycleID; 
SETREG(0,0); RemIntServer(vertb, ADR(CycleInfos[i].int)); 
CycléInfos[i].VP := NIL; 

END EndCycle; 


VAR 
DefaultRect: Rectangle; 


PROCEDURE InitIFFInfo(Info: IFFInfoTypePtr; 
RP: RastPortPtr; 
VP: ViewPortPtr; 
VAR Rect: RectanglePtr) ; 
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FF 


BEGIN BEGIN 
BYTEBuffer [out] := to - from - 1; 
WITH ЕР DO INC(out); 
IF Rect=NIL THEN WHILE from« to DO 
Rect := ADR(DefaultRect); BYTEBuffer [out] := At [from]; 
WITH DefaultRect DO INC(out) ; 
minX := 0; minY := 0; INC( from) ; 
maxX := bitMap’.bytesPerRow * 8 - 1; END; 
maxY := bitMap.rows - 1; END CopyUnchanged; 


BEGIN 
at := 1; 


Infq.BMHD.width := Beet nai - Beet .тіпХ + 1; 
Info.BMHD.height := Beet na" - Rect'.minY + 1; IF (At(at]-At[at-1]) AND (At [at]sAt Detail) AND (at+1<Length- 
WITH Info.BMHD DO ) THEN 
depth := bitMap.depth; IF last#at-1 THEN 
left := 0; CopyUnchanged(1ast,at-1); 
top := 0; 
masking 
transCol := 0; 
sernWidth := bitMap‘.bytesPerRow % 8; 
sernHeight bitMap .rows; 
IF sernWidth<640 THEN UNTIL (At (188%) ЖАҒ(а8)) OR (at-last=128) OR (at=Length); 
xAspect := 10; BYTEBuffer [out] := 257+last-at; ` 
ELSE INC(out); 
xAspect := 5; BYTEBuffer [out] := At [last]; 
END; INC (out); 
IF sernHeight>400 THEN last := at; 
INC(xAspect, xAspect) ; IF at=Length THEN EXIT END; 
END; ELSIF (at-last)=128 THEN 
yAspect := 11; (х- Copy Unchanged: 
END; CopyUnchanged(last,at); 
END; (ж WITH ВР DO *) last := at; 
END; 
(%------ Initialize ОМАР: INC(at); 
IF at=Length THEN EXIT END; 
WITH Info .CMAP DO END; 
colorOnt := VP'.colorMap .count; IF at#last THEN CopyUnchanged(last,at) END; 
FOR 1 := 0 TO colorCnt-1 DO len := Write(OutH,Buffer,out); 
ColorConv := GetROBA(VP .colorMap, i); INC(BodyLength, out) ; 
IF ColorConv>OFFFH THEN ColorConv := 0 END; INC(FileLength, out) ; 
red [1] := UByte(CAST(CARDINAL, CAST(BITSET, RETURN len; 
CARDINAL(SHIFT(ColorConv,-8))) * [0..3])); END Compress; 
green[1] := UByte(CAST(CARDINAL, CAST(BITSET, 
* — CARDINAL(SHIFI(ColorConv,-4))) * [0..3])); PROCEDURE ShiftLine(At: ADDRESS); 
blue [1] := UByte(CAST(CARDINAL,CAST(BITSET, 
г CARDINAL(ColorConv)) * [0..3] )); VAR 
Sourcelong,sourcebit,destlong,destbit: CARDINAL; 


BEGIN 
Initialize CAMG: ShiftSource := At; 
А, sourcelong := 0; 
WITH Info .CAMG DO sourcebit := 31-ShiftWidth; 
viewType :- ViewTypeset[] 5 destlong := 0; 
IF lace IN ҮР .пойев THEN INCL(viewType,Lace) END; destbit := 31; 
IF hires IN VP'.modes THEN INCL(viewType,Hires) END; SniftBuffer[0] := LONGSET[]; 
IF dualpf IN VP'.modes THEN INCL(viewType,DblPF) END; FOR i:=1 TO BitsToShift DO 
IF ham ІМ VP.modes THEN INCL(viewType,HoMod) END; IF sourcebit IN ShiftSource [sourcelong] THEN 
IF extraHalfbrite IN VP'.modes THEN INCL(viewType,Extra) END; INCL(ShiftBuffer[destlong],destbit); 
END; END; 
d IF sourcebit=0 THEN 
Info.IFFTitle := IFFTitleSet(BMHD,CMAP, САМО) ; sourcebit := 31; 


INC(sourcelong); 
END InitIFFInfo; ELSE 
DEC(sourcebit); 
END; 
PROCEDURE WriteILBMAll(Name: ARRAY OF CHAR; IF destbit=0 THEN 
Info: IFFInfoTypePtr; ` destbit := 31; 
BM: BitMapPtr; INC(destlong); 
FirstLine, LeftOffset: INTEGER; ShiftBuffer[destlong] := LONGSET[]; 
CompressIt: BOOLEAN): BOOLEAN; ELSE 


TYPE DEC(destbit); 
BufPtr = POINTER TO ARRAY[O..255] OF UByte; 


PROCEDURE Compress(At: BufPtr; Length: LONGINT): LONGINT; END ShiftLine; 
VAR 


at, last, out, len: LONGINT; (ж-. MAIN: ------%) 


PROCEDURE CopyUnchanged(from,to: LONGINT); Listing 1. (Fortsetzung) 
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OutH := Open(ADR(Name) ‚newFile); 
IF OutH=NIL THEN 
IFFError := iffOpenfailed; 
RETURN FALSE; 
END; 
TextBuffer [0] := "FORM"; 
TextBuffer[2] := "ILBM"; 
len :- Write(OutH,TextBuffer,12); 
IF len#12 THEN 
Close(OutH); 
OutH := NIL; 
IF DeleteFile(ADR(Name)) THEN END; 
IFFError := iffReadWritefailed; 
RETURN FALSE; 
END; 
FileLength : 


(%------ BMHD: 


IF ВМНО IN Info.IFFTitle THEN — (* in fact, ВМНО MUST be set *) 


WITH Info DO 

TextBuffer[ 0) := "BMHD^; 

LONGBuffer[ 1] := 20; (ж Length X) 

WORDBuffer[ 4] := BMHD.width; 

WORDBuffer'( 5] := BMHD.height; 

WORDBuffer[ 6] := BMHD.left; 

WORDBuffer([ 7) := BMHD.top; 

BYTEBuffer (16) := BMHD.depth; 

BYTEBuffer (17) BMHD.masking; (* special masking *) 

IF CompressIt THEN (* compression *) 
BYTEBuffer[18] := 1; 

ELSE 
BYTEBuffer[18] := 0; 

END; 

BYTEBuffer[19] := 0; (* pad *) 

WORDBuffer (10) := BMHD.transCol; (* transparent Color X) 

BYTEBuffer (22) := BMHD.xAspect; 


BYTEBuffer [23] := BMHD.yAspect; 


WORDBuffer (12) := BMHD.scrnWidth; 
WORDBuffer'[13] := BMHD.scrnHeight; 
len := Write(OutH, Buffer,28) ; 
INC(FileLength, 28) ; 


IF CMAP IN Info.IFFTitle THEN (Ж this has to be set, 
WITH Info DO 

TextBuffer [0] := “CMAP”; 

LONGBuffer [1] := CMAP.colorCnt * 3; 

IF ODD(LONGBuffer'(1]) THEN INC(LONGBuffer'[1]) END; 

FOR 1:20 TO CMAP.colorCnt-1 DO 
BYTEBuffer[ 84341) := UByte(ORD(CMAP.red [1]) * 16); 
BYTEBuffer[ 943*1] := UByte(ORD(CMAP.green[1]) * 16); 
BYTEBuffer (104341) := UByte(ORD(CMAP.blue [1]) * 16); 

END; 

len := Write(OutH,Buffer,LONGBuffer (1148); 

INC(FileLength, LONGBuffer (1148); 


IF GRAB IN Info.IFFTitle THEN 
TextBuffer [0] := "GRAB"; 
LONGBuffer (1) := 8; 
WORDBuffer[4] := Info .GRAB.hotX; 
WORDBuffer (5) Info .GRAB.hotY; 
len := Write(OutH,Buffer,12); 
INC(FileLength, 12) ; 


TextBuffer [0] 

LONGBuffer[1] : 

BYTEBuffer [8] :- Info .DEST.depth; 
BYTEBuffer (9) 0; 

WORDBuffer [5] := Info”.DEST.planePick; 
WORDBuffer (6) := Info .DEST.planeOnOff; 
WORDBuffer (7) := Info .DEST.planeMask; 
len :- Write(OutH,Buffer,16); 
INC(FileLength, 16) ; 


IF САМО IN Info .IFFTitle THEN 
TextBuffer'[0] "CAMG"; 
LONGBuffer[1] := 4; 
LONGBuffer'[2] := CAST(LONGCARD, Info . CAMG. viewType) ; 
len := Write(OutH,Buffer,12); 4 
INC(FileLength, 12) ; 


IF CRNG IN Info.IFFTitle THEN 
1:20; 
WHILE 1 < LONGINT(Info'.CRNG.count) DO 
WITH Info .CRNG.data[1] DO ` 
TextBuffer [0] := "CRNG"; 
LONGBuffer[1] := 8; 
WORDBuffer'[4] := 0; 
WORDBuffer'[5] := rate; 
IF on THEN 
WORDBuffer'[6] := 1; 
ELSE 
WORDBuffer (6) := 0; 
END; 
IF NOT(forward) THEN 
INC(WORDBuffer'[6],2) ; 
END; 
BYTEBuffer [14] := low; 


BYTEBuffer'[15] := high; 
len := Write(OutH,Buffer,16); 
INC(FileLength, 16); 


BodyPos FileLength; 

TextBuffer [0] := "BODY"; 

len := Write(OutH,Buffer,8); 

INC(FileLength,8); 

BodyLength := 0; 

i := 0; 

TrueleftOffset := CAST(CARDINAL,CAST(BITSET,LeftOffset) * (4..15]); 

TrueWidth := CAST(CARDINAL,CAST(BITSET, Info .BMHD.width + 15) * (4. 
а); 


WHILE 1« LONGINT(Info .BMHD.depth) DO 
BitMaps[i] := BM.planes[i]; 
INC(BitMaps[1],FirstLine * LONGINT(BM.bytesPerRow) + 
TrueleftOffset DIV 8); 
INC(1); 
END; 


LineLength := TrueWidth DIV 8; 


NeedToShift := (TrueLeftOffset # LeftOffset) 
OR (TrueWidth # Info .BMHD.width); 
IF NeedToShift THEN 
ShiftWidth := LeftOffset - TrueleftOffset; 
BitsToShift := Info .BMHD.width; 
END; 


IF CompressIt THEN 
Line := 0; 
WHILE Line« Info .BMHD.height DO 
Plane := 0; 
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WHILE Plane < LONGINT(Info .BMHD.depth) DO 
IF NeedToShift THEN 
ShiftLine(BitMaps[Plane]); 
len := Compress(ADR(ShiftBuffer),LineLength); 
ELSE 
len := Compress(BitMaps(Plane],LineLength); 
END; 
INC(BitMaps([Plane],BM .bytesPerRow); 
INC(Plane); 
END; 
INC(Line); 
END; 
ELSE 
Line := 0; 
WHILE Line« Info .BMHD.height DO 
Plane := 0; 
WHILE Plane < LONGINT(Info .BMHD.depth) DO 
IF NeedToShift THEN 
ShiftLine(BitMaps(Plane]); 
len := Write(OutH, ADR(ShiftBuffer) ,LineLength) ; 
ELSE 
len := Write(OutH,BitMaps[Plane],LineLength) ; 
END; 
INC(FileLength, LineLength) ; 
INC(BodyLength, LineLength) ; 
INC(BitMaps[Plane] ,BM .bytesPerRow) ; 
INC(Plane) ; 
END; 
INC(Line); 
END; 
END; 
IF ODD(FileLength) THEN 
BYTEBuffer [0] := 0; 
len := Write(OutH,Buffer,1); 
INC(FileLength); 
END; 


len := Seek(OutH,BodyPos+12,beginning) ; 
LONGBuffer (0) := BodyLength; 
len := Write(OutH,Buffer,4) ; 


len :- Seek(OutH,4, beginning); 

LONGBuffer [0] := FileLength; 

len := Write(OutH,Buffer,4); 

Close(OutH) ; x 

ОШЕН := NIL; 

IF len#4 THEN ` 
IF DeleteFile(ADR(Name)) THEN END; 
IFFError := iffReadWritefailed; 
RETURN FALSE; 

ELSE 
RETURN TRUE; 

END; 

END WriteILBMA11; 


PROCEDURE WriteILBM(Name: ARRAY OF CHAR; 
RP: RastPortPtr; 
VP: ViewPortPtr; 

Rect: RectanglePtr; 

CompressIt: BOOLEAN): 


BEGIN 


InitIFFInfo(ADR(IFFInfo) ,RP,VP,Rect) ; 


RETURN WritelLBMAll(Name,ADR(IFFInfo),RP'.bitMap, 
Rect .ninY,Rect .піпХ,Сопргевв1%); 


END WriteILBM; 


PROCEDURE WriteILBMScreen(Name: ARRAY OF CHAR; 
Sereen: ScreenPtr; 

Rect: RectanglePtr; 

CompressIt: BOOLEAN): 
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WITH Screen’ DO 


RETURN WriteILBM(Name, ADR(rastPort) ,ADR(viewPort) ‚Rect,CompressI- 
%; 
END; 


END WriteILBMScreen; 


PROCEDURE CleanUp(); 


BEGIN 
IF InH #NIL THEN Close(InH ) END; 
IF OutH#NIL THEN Close(OutH) END; 
FreeMen(Buffer,768) ; 

END CleanUp; 


Initialization: 


Buffer := AllocMem(768,MemReqSet( memClear) ); 
Assert(Buffer#NIL,ADR(”Not enough ChipMem !!!”)); 
TextBuffer := Buffer; 
LONGBuf fer Buffer; 
WORDBuffer Buffer; 
BYTEBuffer Buffer; 
RQBuffer :- ADDRESS(Buffer+256) ; 
InH := NIL; OutH := NIL; 
FOR 1:-0 TO 31 DO CycleInfos[i].VP:=NIL END; 
TermProcedure(CleanUp) ; 
END IFFSupport. 


Listing 1. (Schluß) 


(%----------------------------- -------------------------------- -- 
IFFSupport.mod 
Fridtjof Siebert 
:Adresse. Nobileweg 67, D-7000-Stuttgart-40 

Telefon. 

:Shorteut. [fbs] 

Version. 1.5 

:Copyright. Markt & Technik Verlag AG 

:Sprache. Modula-II 

:Compiler. M2Amiga v3.2 

:Imports. LoadBody.asm [fbs] 

:History. V1.1 [fbs] 27-Jul-88: Erste veroeffentlichte Version 

:History. V1.2 [fbs] 16-Nov-88: Fehlerkorrektur 
(NIL-RectanglePtr) 

V1.3 [fbs] 28-Dec-88: kleine Aenderungen, angeregt 
von 5. Salewski 

V1.4 [fbs] 23-Mar-89: Fehlerkorrektur (ExtraHB) 

V1.5 [fbs] 03-Jun-89: Anpassung fuer v3.2, Fehler- 
korrektur (Add/RemInt- 
Server()-Bug (3.2)) 

PROCEDUREn für IFF-Bilder (Load, Save, 

ColorCyeling). 
----- ----------------------------------------------------------%) 


:History. 


History. 
:History. 


DEFINITION MODULE IFFSupport; 


FROM Intuition IMPORT ScreenPtr, NewScreen, WindowPtr, NewWindow; 

FROM Graphics IMPORT BitMapPtr, RastPortPtr, ViewPortPtr, 
RectanglePtr; 

FROM Exec IMPORT UByte; 


(%----. - Types: - 


TYPE 
IFFTitles = (BMHD,CMAP,GRAB,DEST, CAMG , CRNG, BODY , SPRT , CCRT , 
CMHD,DPPV); 
IFFTitleSet = SET OF IFFTitles; 
(% SPRT,CCRT,CMHD,DPPV not implemented !!! ж) 


Listing 2. Das zugehörige Definitionsmodul 
»IFFSupport.def« 
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ViewTypes = (vt0,Ersy,Lace,LPen,vt4,vt5,vt6,Extra,Gaud,Color, ` 
Db1PF,HoMod, vt12,vt13,vt14,Hires,v16) ; 
ViewTypeSet = SET OF ViewTypes; 
(* which ViewModes are selected X) 


The Structure that keeps all the data: 


IFFInfoTypePtr = POINTER TO IFFInfoType; 
IFFInfoType = RECORD 
(% This contains all Data needed for a Picture *) 


(%------ Which Data is availble: 
IFFTitle: IFFTitleSet; (% all Sub-Records, whose equally *) 
(* named Flag 18 set here, contain readable data ж 


Information on BitMap: 
BMHD: RECORD 


width,height: INTEGER; (% the Picture's Size ж) 

depth: UByte; (% it's Depth (how many BitPlanes) *) 
left,top: INTEGER; (* it's Location ж) 
masking: UByte; (% Masking (see Documentation) ж) 
transCol: INTEGER; (% Transparent Color ж) 
xAspect,yAspect: UByte;(* Verzerrung ж) 
sernWidth,scrnHeight: INTEGER; (* The Image's Screen's Size*) 


Information on Colors: 
CMAP: RECORD 


colorOnt: CARDINAL; (* Number of Colors used ж) 
red,green,blue: АВНАҮ(0..631 OF UByte; 
(% the Colors (I hope for 6 Bitplanes to be possible anytime) *) 
END; 


(%------ Information on HotSpot: 
GRAB: RECORD 


hotX,hotY: INTEGER; (% Hot-Spot of this Image (if exists *) 


Information on Destination-Bitmap: ------*) 
DEST: RECORD 
depth: UByte; 
planePick: CARDINAL; 
planeOnOff: CARDINAL; (* set or clear other Planes ? 
planeMask: CARDINAL; (* planes to be changed 


(* number of Planes 


Information on any Special ViewMode: ------%) 
CAMG: RECORD 
viewType: ViewlypeSet; (ж ViewMode 
END; 


Information on ColorCycling: *) 
CRNG: RECORD 
count: CARDINAL; (* Number of ColorCyelings ж) 
data: ARRAY[0..15] OF RECORD 


rate: INTEGER; (% velocity, 800H is 60 per second ж) 

on: BOOLEAN; (* decide, wether CRNG is active or not *) 
forward: BOOLEAN;(* Direction (DPaint) ж) 
low,high: UByte; (* lower and upper Color of this Range X): 


Internal Information: 
Internal: RECORD 
CycleID: CARDINAL; (* to distinguish different cyelings X) 
END; 
END; 


VAR 
IFFInfo: IFFInfoType; 


(*------- ------- The NewSereen-Structure. -*) 
(% this can be used to open the Screen, if dontopen is specified ж) 


VAR 
NuScreen: NewScreen; 
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The NewWindow-Structure. 
(* this can be used to open the Window later. Don't forget . 
(* to put SereenPtr in NuWindow.screen !!! 


VAR 
NuWindow: NewWindow; 


(х- -  Error-Message: 
(% IFFError contains Error-Number if Read- ог WriteILBM failed. *) 


TYPE 
IFFErrors = (iffNoErr, iffOutofMen, iffOpenScreenfailed, 
iffOpenWindowfailed, iffOpenfailed,iffWrongIFF, 
'AffReadWritefailed); 
VAR 
IFFError: IFFErrors; 


(ж Read. ТІВМ: 
ТҮРЕ 


ReadILBMFlags = (front, visible,dontopen, window) ; 
ReadILBMFlagSet = SET OF ReadILBMFlags; 


PROCEDURE ReadILBM(name: ARRAY OF CHAR; Flags: ReadILBMFlagSet; 
VAR Screen: ScreenPtr; 
VAR Window: WindowPtr): BOOLEAN; 
М 


(* Name: The IFF-Filename x) 

(* Flags: Y 2 ж) 

(* -front: decides if Screen is first or last while loading 
(* -visible: decides if display should be turned off (faster) 

(* -dontopen: avoids to open the Screen. Returned value is NIL 
(ж window: if set, an Window of the same size as the Image 

(ж is opened. So, Gadgets etc. can be added to it. 

(* Screen: Pointer to Screen-structure of opened Screen 

(* Window: Pointer to the opened Window or NIL if no window set.*) 
(* Result: FALSE if error occured. Then there's no Screen. *) 


(ж -----. ---------- Start Colorcycling: 


PROCEDURE DoCycle(Info: IFFInfoTypePtr; Screen: ScreenPtr): BOOLEAN; 
(ж this should create an interrupt, that does cycling. You ж) 

(* needn't worry, whether there's cycling data or not. Don't X) 

(* forget to call EndCyele to remove the Cycling-Interrupt ! X) 

(ж if result is false, an error occured. Don't call EndCycle *) 

(* in this case! 


(* --------------- End Coloreycling: 


PROCEDURE EndCycle(Info: IFFInfoTypePtr); 
(* remove cycling-Interrupt 


(* --- Initialize ВМНО, CMAP & САМО for WriteILBMAll: --- ж) 


PROCEDURE InitIFFInfo(Info: IFFInfoTypePtr; 
RP: RastPortPtr; 
VP: ViewPortPtr; 
VAR Rect: RectanglePtr); 


Initialize essential parts of IFFInfoType-Variable. 

used to simplify the initialization of an IFFInfoType 

RP: RastPort containing the BitMap etc. 

VP: ViewPort containing the Colors, ViewModes etc. *) 
The Rectangle Region in your RastPort, that ж) 
should be saved ог NIL to save complete RastPort %) 


Save an ILBM-File: 


PROCEDURE WriteILBMAll(Name: ARRAY OF CHAR; 

Info: IFFInfoTypePtr; 

BM: BitMapPtr; 

FirstLine, LeftOffset: INTEGER; 

Сопргевв1%: BOOLEAN): BOOLEAN; 
(* Saves IFF-File named: Name x) 
(* Low-Level Procedure. You should use it to save Pictures ж) 
(* with ColorCycling and things like that. x) 
(* To save Screens, Windows or so use the other Procedures ! x) 
(* Info.IFFTitle must have set the Flags of all initialized ж) 


AMIGA-SONDERHEFT 7 


(% Sub-Records 
(* BM: contains the Graphicdata. In fact BM doesn't 
t have to be part of а RastPort. It can be used 
to save a MaskPlane. Then BM has to contain 
one extra Plane and BM.depth and 
Info .BMHD.depth have to be increased by 1. 
FirstLine: is the TopEdge within BM 
LeftOffset: LeftEdge within BM. Must be a Word-Address, 
i.e. 16%n 
an examble to call this is the Implementation of WriteILBM() 
Save a RastPort and ViewPort ILBM-File: 


PROCEDURE WriteILBM(Name: ARRAY OF CHAR; 
RP: RastPortPtr; 
VP: ViewPortPtr; 
Rect: RectanglePtr; 
CompressIt: BOOLEAN): BOOLEAN; 


Creates an ILBM-File 
File's Name 
RP: RastPort containing the BitMap etc. 
VP: ViewPort containing the Colors, ViewModes etc. 
Rect: The Rectangle Region in your RastPort, that 
Should be saved or NIL to save hole RastPort 
Compressit: Create compressed ILBM-File or not ? 
Result is FALSE if any Error occured. 
example to save a Window: 
OK := WriteILBM("Test.iff”, 
g MyWindow .rPort, 
ADR(MyWindow screen .viewPort, 
TRUE); 


Save a Screen as ILBM-File: 


PROCEDURE WriteILBMScreen(Name: ARRAY OF CHAR; 
Screen: SereenPtr; 
Rect: RectanglePtr; 
CompressIt: BOOLEAN): BOOLEAN; 


(* This creates an ILBM-File from a Screen 

(* Name: File's Name 

(* Screen: Screen to be saved 

(* Rect: The Rectangle Region in your Screen, that 

(ж should be saved ог NIL to save hole Screen 

(% CompressIt: ‚Create a-Compressed ILBM-File 

(* Returns TRUE if no Error occured. 

(* example: OK:sWriteILBMSereen("Test.iff",MyScreen,NIL,TRUE); 
` 


END IFFSupport. 


Listing 2. (Schluß) 


ShowIFF.mod 
Fridtjof Siebert 
:Adresse. Nobileweg 67, D-7-Stgt-40 
:Telefon. 
:Shorteut. [fbs] 
1.0 
20.04.88 
Markt & Technik Verlag AG 
Modula-II 
M2Amiga 
IFFSupport [fbs]. 
none. 
IFF-Ladeprogramm fuer IFF (ILBM)-Bilder. 
emerkung. Syntax: ShowIFF «filename?» 


MODULE ShowIFF; 
FROM SYSTEM IMPORT ADR, ADDRESS, SHIFT, BITSET, LONGSET, CAST; 
FROM Arguments IMPORT NumArgs, GetArg; 


FROM Intuition IMPORT ScreenPtr,CloseScreen,DisplayBeep,WindowPtr; 
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FROM IFFSupport IMPORT ReadILBM, ReadILBMFlags, ReadILBMFlagSet; 
FROM Dos IMPORT Delay; 


VAR 
MySereen: ScreenPtr; (ж the Picture's ScreenPointer x) 
WindowDummy: WindowPtr; (* only a dummy for NIL-Windowpointer *) 
Name: ARRAY[0..79] OF CHAR; (* the Picture's Name ж) 
length: INTEGER; (% dummy for receiving Name's Length %) 
Ciapra [OBFEO01H]: SET ОҒ (80,51,52,53,54,85,11); 
(* Ciapra is a Hardware-Register. Bit #6 contains left Button *) 


IF NumArgs() #0 THEN 

GetArg(1,Name, length); 
ELSE 

HALT; (* a silly guy didn't say which pic I should load *) 
END; 


Wé - Read and Show Pic: -*) 


IF ReadILBM(Name ReadILBMFlagSet{ front, visible} ‚MyScreen, WindowDun- 


my) THEN 


WHILE lmb IN Ciapra 00 Delay(3) END; 


(* that's bad style, but it's the easiest way to wait for left B- 


utton *) 
CloseScreen(MyScreen); (* close the Screen X) 


ELSE 


DisplayBeep(NIL); (% any error occured: lets display a Beep ! *) 


END; 


END ShowIFF. That's all. Wasn't it easy ??? 


Listing 3. »ShowIFF«, die Laderoutine für IFF-Bilder Ш 


(Ras cpa ec acer tis rs ee €—— e 
:Programm. ^ ShowCycle.mod 4 
:Autor. Fridtjof Siebert 
Adresse. Nobileweg 67, D-7-Stgt-40 
Telefon. 

:Shortcut. [fbs] 
:Version. 1.0 
:Datum. 20.04.88 
. 1Copyright. Markt & Technik Verlag AG 
:Sprache. Modula-II 
:Compiler. M2Aniga 
:Imports. IFFSupport [fbs]. 
:UpDate. none. 
:Inhalt. Demo zu IFFSupport für Colorcycling. 
iBemerkung. Syntax: ShowCycle «filename?» 


MODULE ShowCycle; 
FROM SYSTEM IMPORT ADR, ADDRESS, SHIFT, BITSET, LONGSET, CAST; 
FROM Arguments IMPORT NumArgs,GetArg; 


FROM Intuition IMPORT ScreenPtr,CloseScreen,DisplayBeep,WindowPtr; 


FROM IFFSupport IMPORT ReadILBM,ReadILBMFlags,ReadILBMFlagSet, 
DoCyele,EndCycle,IFFInfo; 


FROM Dos IMPORT Delay; 
VAR 


MySereen: ScreenPtr; (* the Picture's ScreenPointer x) 
WindowDummy: WindowPtr; (* only a dummy for NIL-Windowpointer *) 


Listing 4. Bilder mit Farbanimationen werden mit. 
»ShowCycle« geladen 
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Name: ARRAY[O..79] OF CHAR; (* the Picture's Name ж) 
length: INTEGER; (* dummy for receiving Name's Length *) 
Ciapra [OBFEOO1H]: SET OF (s0,51,52,53,54,85,1mb); 

(* Ciapra is a Hardware-Register. Bit #6 contains left Button X) 


IF NumArgs() #0 THEN 
GetArg(1,Name,length); 
ELSE 


HALT; (* a silly guy didn't say which pic I Should load x) 


Read and Show Pic: EA 


IF ReadILBM(Name,ReadILBMFlagSet[ front,visible] ‚MyScreen, WindowDun- 


start ColorCycling: GA 


IF DoCycle(ADR(IFFInfo),MyScreen) THEN END; 


WHILE lmb IN Ciapra DO Delay(3) END; 
(* bad style, but the easiest way to wait for left Button x) 


(*---- stop ColorCyeling (this mustn't be forgotten 111) ---*) 
EndCycle(ADR(IFFInfo)); 
CloseScreen(MyScreen); (* close the Screen %) 


ELSE 


DisplayBeep(NIL); (* any error occured: lets display a Beep ! X) 
END; 


END ShowCycle. That's all. Wasn't it easy ??? 


Listing 4. (Schluß) 


(We ele 
:Programm. ShowOvsc.mod 
Autor. Fridtjof Siebert 


Adresse. Nobileweg 67, D-7000 Stuttgart 40 
:Telefon. 
:Shorteut. [fbs] 
:Version. 1.0 
:Datum. 26-Feb-89 
:Copyright. Markt & Technik Verlag AG 
:Sprache. Modula-II 
:Compiler. M2Amiga v3.1d 
:Imports. IFFSupport [fbs]. 
:UpDate. none. 
:Inhalt. Demo zu IFFSupport für Overscan-Coloreyeling-Bilder. 
iBemerkung. Syntax: Әһон0увс «filename? 
Ai 


MODULE ShowOvse; 


FROM SYSTEM IMPORT ADR; 

FROM Arguments IMPORT NumArgs, GetArg; 

FROM Graphies IMPORT GfxBasePtr, ViewModes; 

FROM Intuition IMPORT ScreenPtr, CloseScreen, DisplayBeep, 
WindowPtr, MakeScreen, RethinkDisplay; 

FROM IFFSupport IMPORT ReadILBM, ReadILBMFlags, ReadILBMFlagSet, 
DoCycle, EndCycle, IFFInfo, NuScreen; 

FROM Dos IMPORT Delay; 

IMPORT Graphics; 


CONST 
minvx 
maxvx 
minvy = 
maxvy = 
author = "ShowOvsc, 1989 by Fridtjof Siebert / AMOK Stuttgart”; 
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VAR 
Му5сгееп: ScreenPtr; (% the Picture's ScreenPointer 
WindowDummy: WindowPtr; (* dummy for NIL-Windowpointer 
Name: ARRAY[O..79] OF CHAR; (* the Picture's Name 
length: INTEGER; (* dummy for Name's Length 
Ciapra [OBFEO01H]: SET OF (s0,51,52,53,54,85,1mb); 
gfx: OfxBasePtr; 


Get Name: 


IF NumArgs() #0 THEN GetArg(1,Name,length) ELSE HALT END; 
gfx := ADR(Graphics); 


Read and Show Pic: 
IF ReadILBM(Name,ReadILBMFlagSet[ front) ,MyScreen,WindowDummy) THEN 


WITH MyScreenviewPort DO 
dxOffset := IFFInfo.BMHD.width; 
dyOffset := IFFInfo.BMHD.height; 
IF NOT(hires IN NuScreen.viewModes) THEN INC(dxOffset,dxOffset) 
END; 
IF lace IN NuSereen.viewModes THEN dyOffset := dyOffset 
DIV 2 END; 
dxOffset := (ORD(gfxX.normalDisplayColumns) - dxOffset) DIV 2; 
dyOffset := (ORD(gfx.normalDisplayRows) ~ dyOffset) DIV 2; 
IF dyOffset<-16 THEN dyOffset := -16 ELSIF dyOffset» 200 
THEN dyOffset := 200 END; Ee d 
IF dxOffset<-32 THEN dxOffset := -32 ELSIF dxOffset> 704 
THEN dxOffset := 704 END; 
IF NOT(hires IN NuScreen.viewModes) THEN dxOffset := dxOffset 
DIV 2 END; 


IF láce IN NuScreen.viewModes THEN INC(dyOffset,dyOffset) 


IF DoCycle(ADR(IFFInfo) ,MyScreen) THEN END; 
WHILE lmb IN Ciapra DO Delay(3) END; 


(* that's bad style, but it's the easiest way to wait for left 
Button X) 


(*---- stop ColorCyeling (this mustn't be forgotten 111) ----X) 
EndCycle(ADR(IFFInfo)); 


CloseScreen(MyScreen); (* close the Screen *) 


ELSE 


DisplayBeep(NIL); (* any error occured: lets display a Beep ! *) 
END; 


END ShowOvsc. That's all. Wasn't it easy ??? 


Listing 5. »ShowOVSC« nutzt die gesamte 
Bildschirmfläche zur Darstellung 


DEFINITION MODULE LoadBody; 
FROM SYSTEM IMPORT BYTE, WORD, ADDRESS, BITSET , LONGSET, FFP; 
(ж 


PROCEDURE LoadBody(a: PROC; b,c:ADDRESS; d,e:LONGINT; f,g:INTEGER;h: 
BOOLEAN) ; 


(* PROCEDURE LoadBody(GetData: PROC; Buffer, BitMapPtrs: ADDRESS; 
LineLength, LineWidth, Height, Depth: INTEGER; 
ExtraPlane: BOOLEAN); 
*) 


END LoadBody. 


Listing 6. »LoadBody.def«: die Definition 
der Maschinenroutine 
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IMPLEMENTATION MODULE LoadBody; 


= 48E7H; 
MOVEML = 4CDFH; 


LoadBody ------ ж) 


BOOLEAN) ; 


ExtraPlane: BOOLEAN) ; 
*) 


BEGIN 
INLINE(MOVEMS, OFFFEH) ; 


SETREG(10, CAST(ADDRESS, a) ) ; 
SETREG(11, ADDRESS(b)) ; 
SETREG(12,ADDRESS(c)); 
SETREG( 2,ADDRESS(d)) ; 
SETREG( 3,ADDRESS(e)); 
SETREG( 5,ADDRESS(f)) ; 
SETREG( 4,ADDRESS(g)) ; 
SETREG( 6,ADDRESS(h)) ; 


FROM SYSTEM IMPORT BYTE, WORD, ADDRESS, BITSET, LONGSET, FFP, 
INLINE, SETREG, REG, CAST; 


PROCEDURE LoadBody(a: PROC; b,c:ADDRESS; d,e:LONGINT; f,g:INTEGER;h: 


(* PROCEDURE LoadBody(GetData: PROC; Buffer, BitMapPtrs: ADDRESS; 
LineLength, LineWidth, Height, Depth: INTEGER; 


FF 


INLINE(041FAH, 000D2H , 03086H , 041FAH, OOOCEH ,03085H, 048E7H , 03F3EH) ; 
INLINE(04E92H, O4CDFH, O7CFCH , 0323CH , O0000H , 03A3CH , O0000H , 03C3CH) ; 
INLINE(00000H, 03003H, 0COC5H , 02A40H, OE546H , ODBFAH , O6000H , OEA46H) H 
INLINE(02C4DH, ODDC2H , 06100H , 00084H , OBO3CH , 00080H ,06212H , 06722H) ; 
INLINE(01EOOH, 06100H, 00076H , 01A80H, 0528DH , 05307H, OGAFAH , 06012H) ; 
INLINE(01EOOH, 06100H , 00066H , 01A80H, 0528DH , 05207H , OBE3CH , 00001H) j 
INLINE(066F4H, OBDCDH , 062CEH ,05246H, OBCA4H , 065B6H ,041ҒАН,00066Н) ; 
INLINE(04A50H, 06738H , 02A7CH , 00000H , 00000H , 06100H , 0003EH , 0BO3CH) ; 
INLINE(00080H, 06210H, 06722H,01E00H, 06100H , 00030H , 0528DH , 05307H) ; 
INLINE(06AF6H, 06014H, 01E00H , 06100H , 00022H , ODBFCH , 00000H , 001019); 
INLINE(OCEBCH, 00000H , 000FFH, 09BC7H, OBA8DH , 062CEH, 05245H , 041FAH) ; 
INLINE(00026H , 0BA50H, 06500H , OFFÓ8H , 0601EH , 01033H , 01000H ,05241H) ; 
INLINE(0B27CH , 00200H , 0650CH , 048E7H, OFF3EH , O4E92H , OACDFH , O7CFFH) ; 
INLINE(04241H, 04E75H , 00001H , 00001H) ; 


INLINE(MOVEML, 07FFFH) ; 
END LoadBody; 


BEGIN 
END LoadBody. 


Listing 7. »LoadBody.mod«: die Implementation 
der Maschinenroutine 


Kompaktor für IFF-Bilder 


Packen wir's an 


enn Sie viel mit Bil- 
dern arbeiten, sind 
die langen Ladezei- 


ten oft störend. Wenn dann 
auch noch der Platz auf der Dis- 
kette knapp wird, gibt es nur ei- 
nes: Die Daten müssen ge- 
packt werden. 

In Sonderheft 6 veröffentlich- 
ten wir den Müllmann »Waste- 
Hunter«. Damit lassen sich Pro- 
grammfiles bis auf die Hälfte ih- 
rer ursprünglichen Länge re- 
duzieren. Der Autor von »Waste- 
Hunter«, Lutz Vieweg, hat sich 
nicht ausgeruht und präsentiert 
in diesem Heft einen IFF-Kom- 
paktor. Wie der Name schon 
verrät, verarbeitet diese IFF- 
Daten, aber auch andere Da- 
tenfiles. Lediglich für Musik-Da- 
ten, genauer Sound-Sample- 
Daten, ist er nicht geeignet. Zu- 
künftige Versionen sollen aber 
auch mit diesen Daten fertig- 
werden. 

Der Kompaktor besteht aus 
zwei Teilen: dem Packer »Wa- 
HuD« und der Routine »de- 
compd«, welche die Daten wie- 
der dekomprimiert. 

Die Anwendung von »Wa- 
HuD« ist dabei wie folgend: Sie 
komprimieren die Daten mit Hil- 
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Der Platz auf Disketten ist immer zu wenig. 

Bilder und andere Daten verschlingen be- 

sonders viel Raum. Mit dem IFF-Kompak- 
tor gehen diese Zeiten zu Ende. 


Von Martin Jobst 


fe von »WaHuD«. Rufen Sie den 
Packer dazu vom CLI aus mit 


WaHuD [-n] filename 


auf. Mit »-n« geben Sie die Gró- 
Be der Suchtiefe (Werte von 0 
bis 6), also die Stárke der Kom- 
primierung, an. In den meisten 
Fállen wird Suchtiefe 1 ausrei- 
chend sein. Das Fenster des 
Packers óffnet sich. Unter 
»READ« sehen Sie die Anzahl 
der Bytes des Files, die bereits 
gelesen wurde. »WRITE« gibt 
die Byteanzahl an, die nach 
dem Packen übrig geblieben 
ist. Ganz rechts sehen Sie, wie- 
viel Prozent das File noch von 
seiner ursprünglichen Länge 
besitzt. Solange der Packer in 
Aktion ist, blinkt der Mauszei- 
ger. 

Wenn der Packer seine Ar- 
beit beendet hat, kónnen Sie 


mit »Y/N« entscheiden, ob das 
File gespeichert werden soll. Ist 
das der Fall, wird es unter dem 
gleichen Namen mit angeháng- 
tem ».d« gespeichert. 

Wie werden komprimierte 
Daten entpackt? Dazu benöti- 
gen Sie »decompd«, welches 
im Assembler-Sourcecode vor- 
liegt. Dieses assemblieren Sie 
und linken es mit dem Pro- 
gramm, das die gepackten Da- 
ten lesen soll. Das können 
Assembler- aber auch C- oder 
Basic-Programme sein. Der 
Linker muß nur das B-Link- 
Verfahren unterstützen. Das 
betrifft etwa den Lattice-C- 
Compiler, den Hisoft-Basic- 
Compiler oder die meisten As- 
sembler (mit Ausnahme des 
Profimat). Bevor Sie »de- 
compd« assemblieren, müssen 
Sie im Sourcecode die Packtie- 


fe der zu ladenden komprimier- 
ten Files (0 bis 6; siehe Source- 
code unter »optionequ«) einstel- 
len. Aus Platzgründen finden 
Sie übrigens »WaHuD« und 
»decompd« nur auf der Pro- 
grammservice-Diskette. 

Beim Aufruf von »decomp« 
aus Ihrem Programm sollten 
Sie folgendes beachten: 

Die Variable » decsource« 
sollte mit der Adresse versehen 
werden, an die das komprimier- 
te Datenfile geladen wurde, 
> decdest« mit der Adresse, 
an der die entpackten Daten 
spáter stehen sollen. 

Dabei werden diese beiden 
Variablen im 32-Bit-Format an- 
gelegt und ebenso wie »_de- 
comp« für »public« erklärt. 
Quell- und Zielbereich dürfen 
sich durchaus überschneiden, 
nur sollten Sie dafür Sorge tra- 
gen, daß die komprimierten Da- 
ten ans Ende - oder besser ein 
paar Words darüber hinaus - 
des Zielbereichs geladen wer- 
den. 

Wenn all das geschehen ist, 
kann die | Dekomprimier- 
Routine mit »bsr - decompd« 
oder »jsr _decompd« gestartet 
werden. so 
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Ob Action-, Denk- 


oder Aben- 
teuerspiel: alle 


profitieren 


von einem guten 
Sound. Mit 
»IFF8SVXLoad« 


vertonen 


Sie Ihre Spiele. 
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Soundausgabe für Modula-Programmierer 


Der gute To 


Von Fridtjof Siebert 
und Martin Jobst 


er Amiga MOdula Klub 

(АМОК) steht für eine 

Menge guter Program- 
me aus der Modula-Ecke. Der 
Club betreibt eine eigene PD- 
Serie, auf der ausschließlich in 
Modula geschriebene Pro- 
gramme veröffentlicht werden. 
Wir stellen Ihnen »IFF8SVX- 
Load« von Amok-Programmie- 
rer Fridtjof Siebert vor. 

Wollen Sie Ihre Spielpro- 
gramme mit einer Klangaura 
versehen, ist »IFF8SVXLoad« 
genau das Richtige. Damit las- 
sen sich Sound-Samples von 
Modula-Programmen aus ab- 
spielen. Die Prozeduren (Li- 
sting 1) lassen sich nur in Modu- 
la-Bibliotheken einbauen. Im 
Beitrag von Frank Staudte auf 
Seite 130 finden Sie einige An- 
regungen, wie Sie Modula- in 
C-Programme konvertieren 
können. 

Im folgenden wollen wir die 
verschiedenen Prozeduren von 
»IFF8SVXLoad« ` beschreiben. 
Das zugehörige Definitions- 
Modul finden Sie in Listing 2. 


Laden... 


Beim Laden von gesampel- 
ten Sounds verwenden Sie fol- 
gende Prozedur: 


PROCEDURE Read8SVX 
(Name: ARRAY OF CHAR; 
MaxChunkSize: LONGCARD; 
ChipMem: BOOLEAN): 
IFF8SVXInfoPtr; 


Diese ládt die Datei »Name«. 
Die Sounddaten werden dabei 
in Blócken der GróBe von »Max- 
ChunkSize« (Byte) geladen. Ist 
»MaxChunkSize« gleich Null, 
wird versucht, alle Daten in ei- 
nen einzigen Block zu laden. 
»ChipMem« entscheidet, ob die 
Datenblocks im Chip-Memory 
liegen sollen, oder nicht. Da- 
durch würde das Abspielen er- 
leichtert, da man die Blocks 
nicht einzeln ins Chip-Memory 
kopieren muß. 

Der Rückgabewert der Pro- 
zedur ist ein Zeiger auf die 
Struktur »IFF8SVXLoad.IFF8 
SVXInfo«, die alle geladenen 


Daten enthält, oder auf »NIL:« 
wenn ein Fehler auftritt. Über 
den Fehler informiert die Varia- 
ble »IFF8SVXLoad.IFF8SVX- 
Errs«. 

Probleme mit dieser Proze- 
dur kann es geben, wenn ein 
langes Sound-File geladen, 
»MaxChunkSize« dabei relativ 
klein und auBerdem der Stack 
nicht sonderlich groB ist. Es 
kann dann zu Fehlermeldun- 


freigeben... · 


gen (Adreßfehler, Stack Über- 
lauf oder Guru) kommen. 

Ist der Sound einmal im Spei- 
cher, wird er mit 
PROCEDURE Dealloc8SVX 

(Info:IFF8SVXInfoPtr); 
freigegeben. 

Damit der Sound abgespielt 
wird, muß das Audio-Device ge- 
öffnet werden. Dies übernimmt 
die Prozedur »OpenAudio:« 
PROCEDURE OpenAudio 
(Channels: CARDINAL; 
Priority: Byte): 


BOOLEAN; 
»Channels« gibt an, wie viele 
Soundkanále angesprochen 


werden sollen, wobei hardware- 
máBig maximal vier móglich 
Sind. »Priority« bestimmt die 
Priorität, mit der die Kanäle akti- 
viert werden sollen. Ihr Werte- 
bereich liegt zwischen -128 
(niedrigste) und 127 (höchste 
Priorität). Bei erfolgreicher Aus- 
führung von OpenAudio() ist 
»TRUE« das Ergebnis, »FALSE« 
signalisiert einen aufgetrete- 
nen Fehler. Genaueres über 
den Fehler erfahren Sie auch 
hier von »IFF8SVXError«. 
Nach dem Öffnen der 
Soundkanäle kann der Sound 


gespielt werden. Dies ge- 
schieht mit: 
PROCEDURE PlaySaniple 
(Info: | IFF8SVXInfoPtr; 
Octave: INTEGER; 
Repeat: CARDINAL; 
Channel: CARDINAL): 
BOOLEAN; 


»Info« ist der von »Read8SVX 
()« übergebene Zeiger, »Octa- 
ve« bestimmt die Oktave des 
abgespielten Sounds und kann 
Werte zwischen 0 und 7 anneh- 


men. Mit der Ausnahme von In- 
strumenten besitzen gesam- 
pelte Sounds meist nur eine 
Oktave (Nummer 0). 

»Repeat« gibt an, wie oft der 
Sound wiederholt werden soll. 
Mit »Channel« bestimmen Sie 
den Audio-Kanal, auf dem der 
Sound ausgegeben wird (Werte 
zwischen 0 und dem bei »Open- 
Audio()« angegebenen Wert 
minus 1). 

Bei erfolgreicher Ausführung 
gibt PlaySample »TRUE« zu- 
rück, ansonsten »FALSE«. Wie- 
der finderi Sie genauere Infor- 
mationen zum Fehler in »IFF8 
SVXError«. 

»PlaySample« 


Sound in einem eigenen Task, 
der die Daten aus dem Fast-Me- 
mory im »Doublebuffering«- 
Verfahren in das Chip-Memory 
kopiert und abspielt. Der bei je- 
dem Durchgang kopierte Block 
hat maximal die bei »Read8 
SVX« angegebene Größe. Bei 
zu kleinen Blocks kann es zu 
Timing-Problemen kommen. 
Da ein neuer Task gestartet 
wurde, gibt »PlaySample« nach 
dem Aufruf sofort die Kontrolle 
an das aufrufende Programm 
zurück. 

Rufen Sie »PlaySample« 
nacheinander mit verschiede- 
nen Kanälen auf, können Sie 
verschiedene Sounds gleich- 
zeitig spielen. Wird es auf einen 
Tonkanal angewandt, in dem 
bereits ein Sound läuft, wird 
dieser abgebrochen und durch 
den neuen ersetzt. Es ist auch 
möglich, auf allen vier Kanälen 
gleichzeitig ein und denselben 
Klang abzuspielen. Dabei kön- 
nen zu hohe Samplingraten 
oder zu klein gewählte »Max- 
ChunkSize« zu leichten Störge- 
räuschen führen. Hier hilft nur 
eines: Experimentieren. 

Während ein Sound gespielt 
wird, darf sein Speicherbereich 
nicht mit »Dealloc8SVX()« frei- 
gegeben werden. 

Mit 
PROCEDURE WaitPlay 
(Channel: CARDINAL); 


wartet der Amiga, bis der mit 
»PlaySample()« gestartete 


spielt den 
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zum Spiel 


Sound in Kanal »Channel« fer- 
tig gespielt ist und springt erst 
danach in den aufrufenden 
Task zurück. Wurde für »Chan- 
nel« »IFF8SVXLoad.AllChan- 
nels« angegeben, wird gewar- 


tet, bis alle Kanäle ihre Ausgabe 
beendet haben. 

Genau gesagt springt »Wait- 
Play« aber schon zurück, kurz 
bevor der letzte Block gespielt 
wird. Dies ermóglicht es, direkt 


IFF8SVXInfo: 


Variablen und Typen 


IFF8SVXInfo.loadedChunks 
IFF8SVXInfo.next/prev 
IFF8SVXInfoVHDR 


IFF8VSXInfo.NAME/COPY/ 
AUTH/ANNO 


IFF8SVXInfo.ATAK/RLSE 


IFF8SVXInfo.BODY 


In einer Variablen dieses Typs werden die Daten eines geladenen 
Sounds gespeichert. Dabei handelt es sich um einen groBen Record, 
der viele Subrecords enthált. Wer lediglich Sounds abspielen móchte, 
braucht über diese Variable nichts Genaueres zu wissen. 


ist ein »SET«, das Flags enthált, die 
für jedes gültige (geladene) 
Subrecord gesetzt sind 

wird nicht benutzt und kann zum 
Linken von mehreren 
»IFF8SVXInfos« verwendet werden 
enthált wichtige Daten wie 
Geschwindigkeit, GróBe, Lautstárke 
etc. des geladenen Sounds 
enthalten die GróBe und einen 
Zeiger auf ein »ARRAY OF CHAR« 
des Soundnamens, Copyrights etc. 
Die GróBe des Arrays betrágt 
maximal 1000 Zeichen. 

speichert Werte für die Lautstárke 
beim Start und Ausklingen von 
Samples. »PlaySample()« 
unterstützt »ATAK & RLSE« nicht. 
erithalt die eigentlichen 
Sounddaten und Informationen, ob 
je Oktave ein einziger Block 
alloziert wurde (MaxChunkSize= 
0). Außerdem enthält es die Größe 
des umfangreichsten Blocks sowie 
ein Flag, das angibt, ob alle Daten 
іт Chip-Memory-liegen oder nicht. 
Es können bis zu acht Oktaven 
gespeichert werden. Pro Oktave 
wird eine Liste von »DataChunk«- 
Records angelegt, die einen Zeiger 
auf die Daten enthält. 


IFF8SVXError: 


Mögliche Fehler: 
iff80K 
iffSOutOfMem 
iff&Openfailed 


iffSReadfailed 
iffSNoIFF 


iffSNoChannel 
iff8OpenDevicefailed 


Enthält die letzte Fehlernummer (IFF8SVXErrs). 


Genauere Informationen zu den Variablen und Typen können 
»IFF8SVXLoad.def« (Listing 2) entnommen werden. 


letztes Kommando war erfolgreich 
nicht genügend Speicher frei ` 
Dos.Open() war erfolglos -> 
Dos.IOErr() 

Dos.Read() war erfolglos - > 
Dos-IOErr() ` 

Datei ist kein gesampelter 
IFF-Sound 

Kein Soundkanal mehr frei 
OpenDevice war erfolglos 


Tabelle 1. Die Funktionen der Variablen von »IFF8SVXLoad« 


AMIGA-SONDERHEFT 7 


danach ohne Zwangspause ei- 
nen anderen Sound zu spielen. 
Das SchlieBen des »Audio- 
Device« schlieBlich geschieht 
mit 
PROCEDURE CloseAudio(); 
Der Task zum Abspielen der 
Sounds wird gestoppt und alle 
gerade gespielten Sounds wer- 
den abgebrochen. 
„In Tabelle 1 finden Sie eine 
Übersicht über die Bedeutung 
der von »IFF8SVX-Load« ver- 
wendeten Variablen und Typen. 
»IFF8SVX« und die folgenden 
Beispiele finden Sie auf der 
AMOK-Diskette Nr. 8. 


Einige Beispiele sollen die 
Anwendung der beschriebe- 
nen Prozeduren verdeutlichen: 


PlaySample (Listing 3) spielt 
von der Workbench den (mit 
<SHIFT linke Maustaste >) ge- 


IFFBSVXLoad .mod 
Fridtjof Siebert 


rogram. 
:Author. 
Address. 
:Shorteut. [fbs] 

Version. 9 

:Date. 18-Sep-88 
:Copyright. 
Language. Modula-II 
:Translator. M2Amiga 
: Imports. 
:UpDate. 
:Contents. 
:Remark. 


none. 


commercial 


:Remark. Software ! 


SYSTEM: 


FROM SYSTEM 


FROM Arts 


Libraries: ------*) 


FROM Audio 
perVol; 


wählten oder im CLI als Argu- 
ment angegebenen Sound auf 
einem Kanal einmal ab. 


PlayRep (Listing 4) wird wie 
»PlaySample« gestartet und 
spielt den Sound endlos ab. 


PlayKeys (Listing 5) wird 
analog gestartet. Danach kann 
man den Sound durch Drücken 
von verschiedenen Tasten in 
unterschiedlichen Tonlagen ab- 
spielen. 


PlayKanon (Listing 6) gibt ei- 
nen gewählten Sound auf allen 
vier Kanälen - jeweils um eine 
halbe Sekunde zeitversetzt - 
einmal aus. so 


Martin Jobst studiert Publizistik und Kommuni- 
kationswissenschaft in Salzburg und arbeitet 
seit drei Jahren als freier Mitarbeiter für Zeit- 
schriften des Markt&Technik Verlages. Sie 
können ihn erreichen über unsere Verlagsan- 
schrift (Markt&Technik Verlag AG, Redaktion 
Sonderhefte, 2. Hd. Martin Jobst, Hans-Pinsel- 
Straße 2, 8013 Haar). 


Nobileweg 67, D-7-Stgt-40 


PD, no commercial use !!! 


MemSystem [bne], Amok #5 


Procedures to load and play sampled sounds. 
Contact me if you want to use this in your own 


IMPORT ADR, ADDRESS, LONGSET, SHIFT, CAST; 


IMPORT Assert, TermProcedure, BreakPoint; 


IMPORT IOAudioPtr, IOAudio, audioName, allocFailed, 


Listing 1. Die Prozeduren von »IFF8SVXLoad« > 
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FROM Dos IMPORT Open, Close, oldFile, Read, FileHändlePtr 
Seek, current; ` 
IMPORT MsgPortPtr, DevicePtr, UByte, Byte, write, 
IOFlagSet, ReplyMsg, GetMsg, OpenDevice, СоруМеп, 
CloseDevice, WaitPort, AddTask, RemTask, TaskPtr, 
Forbid, Permit, NodeType, MsgPortAction, FindTask, 
Wait, Signal, AllocSignal, FreeSignal; 
FROM ExecSupport IMPORT CreatePort, DeletePort, NewList, BeginIO, 
AbortI0; 

Standard: 
FROM Strings IMPORT Compare, first, last; 
(ж Modules: 


FROM MemSystem IMPORT ErrHeader, Allocate, AllocMem, Deallocate, 
YesNoRequest, RETRY, CANCEL, ExitQuiet; 


FROM Exec 


CONSTANTS: 


CONST 
unity = 10000H; (* This is Fixed(1) = 1.0000H *) 


sCompNone = 0; (% по compression *) 
sCmpFibDelta = 1; (* Fibonacci-Delta encoding *) 


TYPE 


Fixed = LONGINT; (* Fixed Point Value (xxxx.xxxxH) *) 
IFF8SVXChunks = (VHDR,NAME, COPY, AUTH, ANNO, ATAK,RLSE, BODY) ; 
IFF8SVXChunkSet = ‚SET OF IFF8SVXChunks; 


Type for Data-Chunks: ------ж) 


DataChunkPtr = POINTER TO DataChunk; 
DataChunk = RECORD 
next: DataChunkPtr; (* to link them *) 
prev: DataChunkPtr; 
Size: LONGCARD; 
data: ADDRESS; 
END; 


(* size of this Chunk X) 
(* where to find it ж) 


(%------ String: 


String = АВВАҮ(0..999) OF CHAR; 
(* This is used for smaller strings ! So don't modify them 
(insert sth.) 1 ж) 


Type to contain loaded data: 
IFF8SVXInfoPtr = POINTER TO IFF8SVXInfo; 
IFF8SVXInfo = RECORD 
loadedChunks: IFF8SVXChunkSet; 
(* all Sub-RECORDs whose flag is set here contain legal data *) 
next,prev: IFF8SVXInfoPtr; 
(* unused. Can be used to link IFF8SVXInfo's 4) 
VHDR: RECORD (% 8SVX's header chunk X) 
oneShotHiSamples: LONGCARD; (* # of Samples in 
shotpart Oct.1 *) 
repeatHiSamples: LONGCARD; (% # of Repeatsamples in 
Oct. 1 ai 
samplesPerHiCycle: LONGCARD; (* # Samples/Cycle or 0 
samplesPerSec: CARDINAL; (* Samplingrate 
eountOctave: Byte; (* counts octaves 
sCompression: Byte; (* Compression type or 
0 if none *) 
volume: Fixed; (* Volume (0..10000H) 
END; 
: RECORD (* Sound's Name *) 
size: LONGCARD; (* Length 
String: POINTER TO String; (% Name 
END; 
RECORD (* Sound's CopyRight *) 
size: LONGCARD; 
string: POINTER TO String; 
END; 
: RECORD (* Sound's Author X) 
size: LONGCARD; 
string: POINTER TO String; 
END; 
: RECORD (* Author's Annotation *) 
size: LONGCARD; 
string: POINTER TO String; 
END; 


ATAK,RLSE: RECORD 
duration: CARDINAL; 
dest: Fixed; 

END; 
BODY: RECORD (* Data of sampled Voice *) 
oneChunk: BOOLEAN; (* Just one Chunk per 
Octave ? 
(* Highest Chunk-Size 


(* Attack & Decay duration *) 
(* Duration in milliseconds *) 
(* Destination Volume ж) 


maxChunkSize: LONGCARD; 

dataInChip: BOOLEAN; 

soundData: ARRAY[0..7] OF DataChunkPtr;(* <= 8 Octaves 
of Data 


IFF8SVXErrs = (iff80K,iff8OutOfMem,iffB8Openfailed,iff8Readfailed, 
iff8NoIFF, 
iff8NoChannel, iff80penDevicefailed); 


(ж-- Variables: 


VAR 


IFF8SVXError: IFF8SVXErrs; (* Last Error *) 


-- internal Variables: 


TYPE 
ExtIOAudio = RECORD 
ioa: IOAudio; 
id: CARDINAL; 
END; 
ExtIOAudioPtr = POINTER TO ExtIOAudio; 
VAR 
InH: FileHandlePtr; 
Buffer: ADDRESS; (* Buffer for Reading / Writing 
TextBuffer: POINTER TO ARRAY[0..63] OF ARRAY[O..3] OF CHAR; 
LONGBuffer: POINTER TO ARRAY[O..63] OF LONGCARD; 
WORDBuffer: POINTER TO ARRAY[O..127] OF CARDINAL; 
LongPtr,LONGPtr: POINTER TO LONGCARD; 
i,j: LONGCARD; 
len: LONGCARD; 
ChunkSize: LONGCARD; 
AllocPort: MsgPortPtr; 
AllocIOB: ` IOAudioPtr; 
Device: DevicePtr; 
SoundPort: MsgPortPtr; 
SoundIOB: IOAudioPtr; 
AllocationMap: ARRAY[O..3] OF Byte; 
SoundXIOA: ARRAY[O..3],[0..1] OF ExtIOAudioPtr; 
SoundInfo: ARRAY[O..3] OF RECORD 
info: IFF8SVXInfoPtr; 
chunk:  DataChunkPtr; (* active Chunk 
oct: CARDINAL; (* octave to play 
repCnt: CARDINA) (* now often to repeat 
bufSize: LONGCARD; (* size of Buffer 
playing: BOOLEAN; (* playing or ready ? 
done: BOOLEAN; (* sound played ? 
dblBuf: BOOLEAN; (* DoubleBuffering ? 
END; 
ChannelDone: ARRAY(0..3] OF ExtIOAudioPtr; 
PlayTask : TaskPtr; 
PlayStack: ADDRESS; 
SoundSignal: LONGINT; 
SoundTask: TaskPtr; 


Load an Octave: 


(* number of bytes read from file X) 
(* size of loaded octave *) 


Ё 
PROCEDURE LoadChunk(Size,MaxSize: LONGCARD; 
Prev: DataChunkPtr; 
CnipMem: BOOLEAN): DataChunkPtr; 
VAR 
Chunk: DataChunkPtr; 
BEGIN 
Allocate(Chunk,SIZE(DataChunk)); 
IF Chunk=NIL THEN 
IFF8SVXError := iff80utOfMem; 


WITH Chunk DO 
prev := Prev; 
IF (Size<=MaxSize) OR (MaxSize=0) THEN 
size :- Size; 
ELSE 
size := MaxSize; 
END; 


*) 
x) 
(* Chunks in Chip-Memory ?*) 


*) 


ж) 
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DEC(Size,size); 
AllocMem(data,size,ChipMem); 
IF data=NIL THEN 
IFF8SVXError := iff8OutOfMem; 
Deallocate(Chunk); 
RETURN NIL; 
END; 
len := Read(InH,data,size); 
IF len#size THEN 
IFF8SVXError := iff8Readfailed; 
Deallocate(data); 
Deallocate(Chunk) ; 
RETURN NIL; 
END; 
IF Size#0 THEN 
next := LoadChunk (Size, MaxSize, Chunk, ChipMem) ; 
IF next=NIL THEN 
Deallocate(data); 
Deallocate(Chunk) ; 
RETURN NIL; 
END; 
ELSE 
next := NIL; 
END; 
END; (% WITH Chunk DO *) 
RETURN Chunk; 
END LoadChunk; 


Load Sampled Sound: 


PROCEDURE Read8SVX(Name: ARRAY OF CHAR; 
MaxChunkSize: LONGCARD; 
СһірМеп: BOOLEAN): IFF8SVXInfoPtr; 
(* Name: Sound's Name 
(* MaxChunkSize; MaxSize of Data-Chunk or 0 to load to a single 
chunk *) 
(* ChipMem: TRUE if you want all chunks in ChipMen. 
(* Resul: Pointer to info of loaded sample or NIL if any 
error ж) 
(ж occured. IFF8SVXError contains errortype. 
VAR 
Info: IFF8SVXInfoPtr; - 
BEGIN hi 
IFF8SVXError := iff60K; 
Allocate(Info,SIZE(Info)); 
IF Info=NIL THEN 
IFF8SVXError := iff8OutOfMem; 


RETURN NIL; 


Open File: 


LOOP d 
InH := Open(ADR(Name) ,oldFile); 
IF InH=NIL THEN 
IFF8SVXError := iff80penfailed; 


File Header: -*) 


len := Read(InH,Buffer,12); 

IF 1еп-0 THEN 
IFF8SVXError := iff8Readfailed; 
EXIT; 

END; 

IF (Compare(TextBuffer [0],first,4, "FORM",TRUE) #0) OR 
(Compare(TextBuffer [2], first,4, "8SVX”,TRUE) #0) THEN 
IFF8SVXError := iff8NoIFF; 


len := Read(InH,Buffer,8); 


IF len#8 THEN 
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IFF8SVXError := iff8Readfailed; 


IF Compare(TextBuffer [0], first,4, "VHDR”,TRUE)=0 THEN 
INCL( Info". 1loadedChunks , VHDR) ; 
len := Read(InH,Buffer,LONGBuffer (1)); 
LONGPtr := Buffer; 
LongPtr := ADR(Info .VHDR); 
FOR 1:20 TO 4 DO 
LongPtr := LONGPtr; 
INC(LongPtr,4); 
INC(LONGPtr, 4) ; 


ELSIF Compare(TextBuffer [0], Tiret, A, "NAME”,TRUE)=0 THEN 
INCL(Info . loadedChunks , NAME) ; 
WITH Info .МАМЕ DO 
size := LONGBuffer'[1]41; 
AllocMem(string, size, TRUE) ; 
IF string=NIL THEN IFF8SVXError := iff8OutOfMem; EXIT END; 
len :- Read(InH,string,size-1); 
IF ODD(size-1) THEN len := Read(InH,Buffer,1) END; 


ELSIF Compare(TextBuffer [0],first,4, "(el ”,TRUE)=0 THEN 
INCL(Info .loadedChunks, COPY) ; 
WITH Info .COPY DO 
size := LONGBuffer [1]41; 
AllocMem(string,size,TRUE); 
IF string=NIL THEN IFF8SVXError := iff80utOfMem; EXIT END; 
len :- Read(InH,string,size-1); 
IF ODD(size-1) THEN len := Read(InH,Buffer,1) END; 


ELSIF Compare(TextBuffer'[0),first,4, "AUTH",TRUE)sO THEN 
INCL(Info .loadedChunks, AUTH) ; 
WITH Info AUT DO 
size := LONOBuffer[1]41; 
AllocMem(string,size,TRUE); 
IF string=NIL THEN IFF8SVXError := iff80utOfMem; EXIT END; 
len := Read(InH,string,size-1); 
IF ODD(size-1) THEN len := Read(InH,Buffer,1) END; ` 


ELSIF Compare (TextBuffer’[0], first,4, “ANNO”, TRUE)=0 THEN 
INCL(Info .loadedChunks, ANNO) ; 
WITH Info .ANNO DO 
size := LONGBuffer [1]+1; 
AllocMem(string,size,TRUE); , 
IF string=NIL THEN IFF8SVXError :- iff80utOfMem; EXIT END; 
len := Read(InH,string,size-1); 


IF ODD(size-1) THEN len := Read(InH,Buffer,1) END; 


ELSIF Compare(TextBuffer [0], first,4, "ATAK", TRUE)sO THEN 
INCL( Info’. loadedChunks , ATAK) ; 
len := Read(InH,Buffer,LONGBuffer'[1]); 
Info.ATAK.duration := WORDBuffer [0]; 
LONGPtr := ADDRESS(LONGCARD(Buffer) + 2); 
Info.ATAK.dest := LONGPtr'; 


ELSIF Compare(TextBuffer'[0],first,4, "RLSE”,TRUE)=0 THEN 
INCL( Info". loadedChunks , RLSE) ; 

_ len := Read(InH,Buffer,LONGBuffer (11); 
Info.RLSE.duration :- WORDBuffer [0]; 
LONGPtr := ADDRESS(LONGCARD(Buffer) + 2); 
Info.RLSE.dest := LONGPtr’; 


Listing 1. (Fortsetzung) 
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PROCEDURE Dealloc8SVX(Info:IFF8SVXInfoPtr) ; 
ELSIF Compare (TextBuffer'[0], first,4, "BODY”,TRUE)=0 THEN 


IF NOT(VHDR IN Info’.loadedChunks) THEN 
IFF8SVXError := iff8NoIFF; 
EXIT; 
END; 
INCL( Info". loadedChunks , BODY) ; 
WITH Info .BODY DO 
oneChunk TRUE; 
dataInChip ChipMem; 
WITH Info .VHDR DO 
ChunkSize := oneShotHiSamples + repeatHiSamples; 
FOR i:=0°TO Info .VHDR.countOctave-1 DO 
soundData[i] LoadChunk (ChunkS1ze,MaxChunkSize, 
NIL,ChipMem); 
IF soundData[i]-NIL THEN EXIT END; 
maxChunkSize := ChunkSize; 
INC(ChunkSize , ChunkSize) ; 
END; 
IF maxChunkSize>MaxChunkSize THEN 
maxChunkSize := MaxChunkSize; 
END; 
END; 
END; 
EXIT; 
Unknown Chunk: 


(* Info: Sound's Info- 
Record 


VAR 
i: CARDINAL; 


BEGIN 
IF Info#NIL THEN 
IF NAME IN Info. loadedChunks THEN 
WITH Info .NAME DO 
IF string#NIL THEN Deallocate(string) END; 
END; 
END; 
IF COPY IN Info .loadedChunks THEN 
WITH Toto OPT DO 
IF string#NIL THEN Deallocate(string) END; 
END; E 
END; 
IF AUTH IN Info.loadedChunks THEN 
WITH Info .AUTH DO 
IF string#NIL THEN Deallocate(string) END; 
END; 
END; 
IF ANNO IN Info’.loadedChunks THEN 


ELSE 
IF ODD(LONGBuffer'[1]) THEN 
len := Seek(InH,current,LONGBuffer [1]41); 
ELSE 


len := Seek(InH,current,LONGBuffer'[1]) ; 
END; 
END; 


(* LOOP *) 


EXIT & Error check: ж) 


IF NOT((VHDR IN Info‘.loadedChunks) OR (BODY IN Info loaded 
Chunks)) THEN 
IFF8SVXError := iff8NoIFF; 

END; 
EXIT; 

END; (ж LOOP *) 

IF IFF8SVXError# iff80K THEN 
Dealloc8SVX(Info) ; 
Info := NIL; 

END; 

Close(InH); InH := NIL; 


RETURN Info; 


END Read8SVX; 


(ж 


- Free DataChunk's Memory: 


PROCEDURE FreeChunks(first: DataChunkPtr); 


BEGIN 


WITH first DO 
IF next#NIL THEN FreeChunks(next) END; 
IF data#NIL THEN 
Deallocate(data); 
END; 
END; 
Deallocate(first); 


END FreeChunks; 


(ж 
(ж 
(ж 
(* 
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WITH Info .ANNO DO $ 
IF string#NIL THEN Deallocate(string) 
END; 
END; 
IF BODY IN Info'.loadedChunks THEN 
FOR 1:20 TO Info .VHDR.countOctave-1 DO 
IF Info .BODY.soundData(i] #NIL THEN 
FreeChunks(Info .BODY.soundData[1]) ; 
END; 
END; 
END; 
Deallocate(Info); 
END; 


END Dealloc8SVX; 


Task to play Sound: 


PROCEDURE PlayTeskProc(); (* $S- si 


VAR 


XIOA: ExtIOAudioPtr; 
1: CARDINAL; 


BEGIN 


100Р 
WaitPort(SoundPort) ; 
XIOA := GetMsg(SoundPort) ; 


END; 


IF (XIOA#NIL) AND (XIOA'.ioa.request.error=0) THEN 


WITH SoundInfo[XIOW.1d) DO 
Forbid(); 
IF done THEN 
ChannelDone[XIOW id] := NIL; 
END; 
IF playing THEN 
IF chunk’.next #NIL THEN 
chunk := chunk next; 
ELSIF repCnt>1 THEN 
DEC(repCnt) ; 
chunk := info'.BODY.soundData[oct]; 
ELSE 
done := TRUE; 
ChannelDone[XIOW.id] := XIOA; 
playing := FALSE; 


Signal (SoundTask , LONGSET{ SoundSignal]) 


END; 

END; 

IF NOT(done) THEN 
playing := TRUE; 
IF dblBuf THEN 


CopyMem(chunk . data, XIOA .10a.data,chunk size): 


ELSE 


XIOK.ioa.data := chunK data; 
END; 
XIOK.ioa.length := chunk size: 
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Begin10(XIOA) ; 
END; 
Permit(); 
END; (% WITH SoundInfo[XIOK.id] *) 
END;  (* IF Msg ok THEN *) 
END;  (* endless LOOP *) 
END PlayTaskProc; 


PROCEDURE OpenAudio(Channels: CARDINAL; Priority: Byte): BOOLEAN; 


(* Channels: Number of soundchannels to allocate 
(* Prioriy: Allocation Priority 


BEGIN 
IFF8SVXError := iff80K; 


Allocation Precedence and Channel: 


AllocIOP .request.message.node.pri -40; 
AllocIOB’.request.message.replyPort:= AllocPort; 


CASE Channels OF 
1: AllocationMap[0] : 
AllocationMap[1] : 
AllocationMap[2] 
AllocationMap[3] 
: AllocationMap[0] : 
AllocationMap[1] : 
AllocationMap[2] 
AllocationMap[3) 
: AlloeationMap[0] : 
AllocationMap[1] 
AllocationMap[2] 
AllocationMap[3) 
: AllocationMap[0] 
AllocationMap[1] 
AllocationMap[2] 
AllocationMap[3] : gol 
END; 
AllocIOB’.data := ADR(AllocationMap); 
AllocIOB.length := SIZE(AllocationMap) ; 


(%------ Open Audio-Device: ------%) 


OpenDevice(ADR(audioName) ,0,A1locIOB, LONGSET[] ) ; 
(* Why doesn't OpenDevice() return it's error ??? X) 


CASE AllocI0B’.request.error OF 
-1,allocFailed: 
IFF8SVXError :- iff80penDevicefailed; 
RETURN FALSE | 
ELSE 
END; 


Device := AllocIOB .request.device; 
Initialize ReplyPort: 


WITH SoundPort? DO 
flags іш signal; 
node.type := msgPort; 
END; 
NewList(ADR(SoundPort .nsgList)); 


Initialize I/0-Block: 


FOR 1:-0 TO 3 DO 
WITH SoundXIOA[1,0] DO 
id := 4; 
1oa.request.message.replyPort 
ioa.request.device := Device; 
WHILE (j<4) AND NOT(j IN CAST(LONGSET, AL1ocIOB .request.unit)) 
Do 
INC(3); 


12 SoundPort; 
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END; 
IF j«4 THEN 
ioa.request.unit := CAST(ADDRESS, LONGSET{ J} ) ; 
DEC(Channels,1); 
ELSE 
ioa.request.unit zs NIL; 
END; 
INC(3); 
‘foa.request.command := write; 
ioa.request.flags := IOFlagSet(4]; (* perVol *) 
. oa.allocKey := AllocIOB .allocKey; 
END; 
SoundXIOA[i,1]" := SoundXIOA[1,0); 
SoundInfo[i].playing := FALSE; 
SoundInfo[i].done := TRUE; 
ChannelDone[i] t= NIL; 


Start PlayTask: 


* Allocate(PlayTask,SIZE(PlayTask’)) ; 
IF PlayTask=NIL THEN ExitQuiet END; 
SoundPort’.sigTask := PlayTask; 
WITH PlayTask’ DO 
spLower := PlayStack; 
spUpper := ADDRESS(LONGCARD(PlayStack) + 1000); 
spReg := spUpper; 
node.type := task; 
node.name ADR( "SamplePlayTask”); 
END; 
AddTask(PlayTask, ADR(PlayTaskProc) ,NIL) ; 


IF Channels>0 THEN 
CloseAudio(); 
IFF8SVXError := iff8NoChannel; 
RETURN FALSE; 

END; 


RETURN TRUE; 


END OpenAudio; 


Close Audio Device: 


(%--------------..-.--------------------------------------------- --*) 


PROCEDURE CloseAudio(); 


BEGIN 
RemTask(PlayTask); 
Deallocate(PlayTask); 
PlayTask := NIL; 
CloseDevice(AllocIOB); 
Device := NIL; 
FOR 1:=0 TO 3 DO 
IF SoundInfo[i].dbiBuf THEN 
WITH SoundXIOA[i,0].10a DO 
IF data#NIL THEN Deallocate(data) END; 
END; 
WITH SoundXIOA[i,1].16a DO 
IF data#NIL THEN Deallocate(data) END; 


PROCEDURE PlaySample(Info: IFF8SVXInfoPtr; 
Octave: INTEGER; 
Repeat: CARDINAL; 
Channel: CARDINAL): BOOLEAN; 


Listing 1. (Fortsetzung) 


(* Info: Sound's IFF8SVXInfo 

(* Octave: Octave to play (0..7) 

(* Repeat: how often to repeat sound 
(* Channel: Channel to play sound 


VAR 
Reply: BOOLEAN; 


Fun Starts: 


IF Info=NIL THEN 
IFF8SVXError 
RETURN FALSE; 

END; 


iff8NoIFF; 


IF Octave >= Info’.VHDR.countOctave THEN RETURN TRUE END; 


WITH SoundInfo[Channel] DO 

Forbid(); 
Reply := done; 
AbortIO(SoundXIOA[Channel,0]); 
AbortIO(SoundXIOA (Channel, 1]) ; 
WITH Info DO 

info := Info; 

chunk := BODY.soundData[Octave]; 

oct := Octave; 

repCnt := Repeat; 

playing FALSE; 

done t= FALSE; 

bufSize := Info .BODY.maxChunkSize; 

IF dblBuf THEN 

FOR 1:=0 TO 1 DO 
WITH SoundXIOA[Channel,1]'.1oa DO 
IF data#NIL THEN Deallocate(data) END; 


dblBuf := NOT(BODY.dataInChip); 
FOR 1:20 TO 1 DO; 
WITH SoundXIOA[Channel,i]'.ioa DO 
period := LONGINT(3584200) DIV LONGINT 
(VHDR.samplesPerSec); 
volume SHIFT(VHDR. volume, -10) ; 
cycles t= 1; 
IF dblBuf THEN 
AllocMem(data, bufSize, TRUE) ; 
IF data=NIL THEN 
IFF8SVXError :- iff80utOfMem; 
RETURN FALSE; 
END; 
ELSE 
data := NIL; 
END; 
END; 
END; 
IF Reply THEN 
IF ChannelDone[Channel] = NIL THEN 
ReplyMsg(SoundXIOA[Channel,0]); 
ReplyMsg(SoundXIOA[Channel,1]); 
ELSE 
ReplyMsg(ChannelDone[Channel]); 


IFF8SVXError := iff80K; 
RETURN TRUE; 


END PlaySample; 


(ж 
CONST 

AllChannels = 4; 
x) 


PROCEDURE WaitPlay(Channel: CARDINAL); 


(* This waits for a channel to complete. 
(% WaitPlay(AllChannels) waits for all channels to finish. 


VAR 
4: CARDINAL; 
x: BOOLEAN; 


BEGIN 
IF Channel« AllChannels THEN 
IF NOT(SoundInfo[Channel].done) THEN 
IF Wait(LONGSET(SoundSignal])-LONOSET(] THEN END; 
END; 5 


100Р 
x := TRUE; 
FOR 1:20 TO 3 DO 
.X := x AND SoundInfo[1].done; 
END; 
IF x THEN EXIT END; 
IF Wait(LONGSET| SoundSignal] )=LONGSET{} THEN END; . 
END; 
END; 
END WaitPlay; 


PROCEDURE CleanUp(); 


BEGIN 
IF PlayTask #NIL THEN 
RemTask(PlayTask); 
Deallocate(PlayTask); 
END; 
IF Device #NIL THEN CloseDevice(AllocIOB) END; 
IF Buffer#NIL THEN Deallocate(Buffer) END; 
IF InH#NIL THEN Close(InH) END; 
IF AllocIOB #NIL THEN Deallocate(AllocIOB ) END; 
IF AllocPort#NIL THEN DeletePort(AllocPort) END; 
IF SoundPort#NIL THEN Deallocate(SoundPort) END; 
IF PlayStack#NIL THEN Deallocate(PlayStack) END; 
FOR 1:20 TO 3 DO 
IF SoundInfo[i].dblBuf THEN 
WITH SoundXIOA[1,0]'.10a DO 
IF data#NIL THEN Deallocate(data) END; 


SoundXIOA[i,1].ioa DO 
IF data#NIL THEN Deallocate(data) END; 


IF SoundXIOA[i,1) #NIL THEN Deallocate(SoundXIOA[1,1]) END; 
END; 
FreeSignal(SoundSignal); 

END CleanUp; 


| 
IF SoundXIOA[i,0] #NIL THEN Deallocate(SoundXIOA[i,0]) END; | 
| 
| 


Initialization: 


ErrHeader := "Error loading Sampled Sound: ”; 
AllocMem(Buffer, 768, TRUE) ; 
Assert(Buffer#NIL,ADR(”Not enough ChipMem !!!”)); 
TextBuffer Buffer; 
LONGBuffer Buffer; 
WORDBuffer Buffer; 
InH := NIL; 
AllocPort := CreatePort(ADR( “Sampled SoundPort”),0); 
IF AllocPort=NIL THEN ExitQuiet END; 
Allocate(AllocIOB,SIZE(AllocIOB)); 
IF AllocPort-NIL THEN ExitQuiet END; 
FOR i:=0 TO 3 DO 
Allocate(SoundXIOA[1,0] ,SIZE(ExtIOAudio)); 
IF SoundXIOA[i,0]-NIL THEN ExitQuiet END; 
Allocate(SoundXIOA[1,1],SIZE(ExtIOAudio)); 
IF SoundXIOA[1,1]-NIL THEN ExitQuiet END; 
SoundInfo[i].dblBuf :- FALSE; 
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SoundInfo[i].done := TRUE; 
END; 
Allocate(SoundPort,SIZE(SoundPort‘)); String = ARRAY[0..999] OF CHAR; 
IF SoundPort=NIL THEN ExitQuiet END; (* This is used for smaller strings ! So don't modify them 
Allocate(PlayStack,1000); (insert sth.) ! *) 
IF PlayStack=NIL THEN ExitQuiet END; 
PlayTask := NIL; Type to contain loaded data: 
SoundSignal := AllocSignal(-1); 
Assert(SoundSignal>0,ADR(”No more Signalbits 1!!”)); IFF8SVXInfoPtr = POINTER TO IFF8SVXInfo; 
SoundTask := FindTask(0); 
Device := NIL; IFF8SVXInfo = RECORD 
TermProcedure(CleanUp) ; ` loadedChunks: IFF8SVXChunkSet; 
END IFF8SVXLoad. (* all Sub-RECORDs whose flag is set here contain legal data *) 


Listing 1. (Schluß) next,prev: IFF8SVXInfoPtr; 
(* unused. Can be used to link IFF8SVXInfo's %) 


VHDR: RECORD (* 8SVX's header chunk *) 

oneShotHiSamples: LONGCARD; (* # of Samples in 
:Program. IFF8SVXLoad.mod shotpart Oct.1 *) 
:Author. Fridtjof Siebert repeatHiSamples: LONGCARD; (* # of Repeatsamples in 
"Address, Nobileweg 67, D-7-Stgt-40 5 Oct. 1 %) 
:Shorteut. [fbs] samplesPerHiCycle: LONGCARD; (* # Samples/Cycle 
:Version. .9 or 0 *) 
:Date. 18-Sep-88 samplesPerSec: CARDINAL; (* Sampling-rate 
:Copyright. PD, no commercial use !!! countOctave: Byte; (* counts octaves 
:Language. Modula-II sCompression: Byte; (* Compression type or 0 
:Translator. M2Amiga if none *) 

MemSystem [bne], Amok #5 volume: Fixed; (* Volume (0..10000H) 


none. END; 


Procedures to load and play sampled sounds. 


Contact me if you want to use this in your own + RECORD (* Sound's Name *) 
commercial size: LONGCARD; (* Length 


Software | string: POINTER TO String; (% Name 
END; 


RECORD (* Sound's CopyRight X) 
size: LONGCARD; 
String: POINTER TO String; 

END; 


: RECORD (* Sound's Author *) 
Size: LONGCARD; 
string: POINTER TO String; 
END; 


RECORD (* Author's Annotation *) 
size: LONGCARD; 


FROM Exec “IMPORT Byte; 2 E: POINTER TO String; 
5 j 


CONSTANTS: o mee mecs u) ATAK,RLSE: RECORD (% Attack & Decay duration *) 
duration: CARDINAL; (* Duration in milliseconds 
dest: Fixed; (* Destination Volume 

END; 


unity = 100008; (ж This is Fixed(1) = 1.0000H *) BODY: RECORD (* Date of sampled Voice *) 
oneChunk: BOOLEAN; (* Just one Chunk per Octave ? %) 


sCompNone = 0; (% no compression *) maxChunkSize: LONGCARD; (* Highest Chunk-Size x) 


sOmpFibDelta = 1; (* Fibonacci-Delta encoding X) dataInChip: BOOLEAN; (* Chunks in Chip-Memory ?*) 
soundData: ARRAY[O..7] OF DataChunkPtr;(* <= 8 Octaves 


of Data %) 


Fixed = LONGINT; (* Fixed Point Value (xxxx.xxxxH) *) 
IFF8SVXErrs = (iff80K,iff80utOfMem,iff80penfailed,iff8Readfailed, 


IFF8SVXChunks = (VHDR,NAME, COPY, AUTH, ANNO, ATAK,RLSE, BODY) ; Aff8NoIFF, iff8NoChannel, iff80penDevicefailed) ; 
IFF8SVXChunkSet = SET OF IFF8SVXChunks; 


Type for Data-Chunks: 


DataChunkPtr = POINTER TO DataChunk; 

DataChunk = RECORD 
next: DataChunkPtr; (* to link them X) IFF8SVXError: IFF8SVXErrs; (% Last Error X) 
prev: DataChunkPtr; 
size: LONGCARD; (* size of this Chunk %) 


DOR ERR Uses АТ) Listing 2. Das Definitionsmudul zu »IFF8SVXLoad« >» 
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PROCEDURE Read8SVX(Name: ARRAY OF CHAR; 
MaxChunkSize: LONGCARD; 
ChipMem: BOOLEAN): IFF8SVXInfoPtr; 


:Input. Name = Sound's Name and Path ж) 
:Input. MaxChunkSize = Maximum Size of Data-Chunks or 0 to 
load to a *) > 
iInput. single chunk *) 
:Input. СһірМеп = TRUE if you want all chunks in ChipMem.*) 
:Result. Pointer to Info of loaded sample ог NIL if any error 
occured. *) 
:Result.  IFF8SVXError contains errortype. x) 
:Semantic.Loads Sampled sound. 


PROCEDURE Dealloc8SVX(Info:IFF8SVXInfoPtr); 


(ж :Input. Sound's Info-Record 
(* :Semantic.Frees Sound's Memory. 


:Input. Channels = Number of soundchannels to allocate 
:Input. Prioriy = Allocation Priority 

:Result. FALSE in case of any error 

:Semantic.Opens Audio Device and allocats Soundchannels 
mote. Detects whether OpenDevice() fails or not! 


PROCEDURE CloseAudio(); 
(* :Semantic. Closes Audio Device. Don't forget this! 


PROCEDURE PlaySample(Info:  IFF8SVXInfoPtr; 
Octave: INTEGER; 
Repeat: CARDINAL; 
Channel: CARDINAL): BOOLEAN; 


:Input. Info = Sound's IFF8SVXInfo ж) 
:Input. Octave = Octave to play (0..7) ж) 
:Input. Repeat = how often to repeat sound ж) 
:Input. Channel = Channel to play sound x) 
:Result. FALSE if any error occured ж) 
:Semantic.Plays sampled sound *) 
:Note. Sounds are played with a second task feeding the audio 
device.*) 

"Note, If you call PlaySample with a sound actually playing 


on the %) 
:Note. specified Channel, the old sound will be stopped. 


AllChannels = 4; 


"PROCEDURE WaitPlay(Channel: CARDINAL); 


(* :Input. Channel = Channel to wait for or AllChannels 
*) 
(* :Semantic. This waits for a channel to ‘complete. 
(* :Semantic. WaitPlay(AllChannels) waits for all channels to 
finish. ж) 


END IFF8SVXLoad. 
Listing 2. (Schluß) 


rogram. PlaySample.mod 
sAuthor. Fridtjof Siebert 
:Address. Nobileweg 67, D-7-Stgt-40 
:Shorteut. [fbs] 
Version. 1.0 
:раќе. 19-5ер-88 
:Copyright. PD 
:Language. Modula-II 
:Translator. M2Amiga 
:Imports. IFF8SVXLoad [fbs], MemSystem [bne] 
:UpDate. none. 
:Contents. Program to play a sampled IFF-Sound. 
:Remark. Usage: PlaySample <iff-soundfile> 


MODULE PlaySample; 
FROM SYSTEM IMPORT ADR, ADDRESS, SHIFT, BITSET, LONGSET, CAST; 


FROM Arts IMPORT Terminate; 


FROM Arguments IMPORT NumArgs, GetArg; 


FROM Dos IMPORT Delay; 


FROM IFF8SVXLoad IMPORT Read8SVX, Dealloc8SVX, IFF8SVXInfoPtr, 
PlaySample, OpenAudio, CloseAudio, WaitPlay, AllChannels; 


CONST 
ProgName = "PlaySample, 1988 by Fridtjof Siebert [Amok]”; 


VAR 
Name: ARRAY[O..79] OF CHAR; (% the Sound's Name ж) 
length: INTEGER; (* dummy for receiving Name's Length *) 
Info: IFF8SVXInfoPtr; (* Sound's Data ж) 


IF NumArgs() #0 THEN 
GetArg(1,Name, length); 
ELSE 
Terminate(0); 
Read and Play Sound: 
Info := Read8SVX(Name,16000, FALSE); (* load sound *) 


IF Info#NIL THEN 
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IF OpenAudio(1,0) THEN (* open audio 


IF PlaySample(Info,0,1,0) THEN (* play sound 
WaitPlay(0); 

END; 

Delay(100); (* wait 2s to get last samples before 
closing audio X) 

CloseAudio(); ^ (X close audio X) 

END; 


Dealloc8SVX(Info); ` (* free sound X) 


END; 


END PlaySample. 


Listing 3. 
»PlaySample« spielt einen Sound einmal durch 


PlayRep.mod 

Fridtjof Siebert 
:Address.  Nobileweg 67, D-7-Stgt-40 
:Shortcut. [fbs] 
Version. 1.0 

19-Sep-88 

PD 

Modula-II 

M2Amiga 

IFF8SVXLoad [fbs], MemSystem [bne] 

none. 
:Contents. Program to play а sampled Sound repeatedly. 
:Remark. Usage: PlayRep <iff-soundfile> 

ZEE SE 


MODULE PlayRep; 


FROM SYSTEM IMPORT ADR, ADDRESS, SHIFT, BITSET, LONGSET, CAST; 


FROM Arts IMPORT Terminate, Assert; 


FROM Arguments IMPORT NumArgs, GetArg; 


FROM Exec IMPORT WaitPort; 

FROM Intuition IMPORT DisplayBeep, NewWindow, WindowPtr, 
WindowFlags, WindowFlagSet, ScreenFlags, 
ScreenFlagSet, IDCMPFlags, IDCMPFlagSet, 
OpenWindow, CloseWindow; 


FROM IFF8SVXLoad IMPORT Read8SVX, Dealloc8SVX, IFF8SVXInfoPtr, 
PlaySample, 
OpenAudio, CloseAudio, WaitPlay, AllChannels; 


CONST 
ProgName = "PlayRep, 1988 by Fridtjof Siebert [Amok]”; 


VAR 
Name: ARRAY[0..79) OF CHAR; (* the Sound's Name x) 
length: INTEGER; (* dummy for receiving Name's Length *) 
Info: IFF8SVXInfoPtr; (* Sound's Data x) 
Window: WindowPtr; 
NuWindow: NewWindow; 


Channel: CARDINAL; (* Active Channel x) 


Get Name: 


IF NumArgs() #0 THEN 
GetArg(1,Name, length); 
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FF 


ELSE 
Terminate(0); 


Open Window: 


WITH NuWindow 
leftkdge :- 
topEdge 


blockPen : 
idempFlags := IDCMPFlagSet[ eloseWindon] ; 
flags := WindowFlagSet[windowSizing, windowDrag, windowDepth, 
windowClose, activate]; 
firstGadget := NIL; 
checkMark := NIL; 
title := ADR("Sound loader АМОК”); 
Screen := NIL; 
bitMap := NIL; 
minWidth := 30; 
minHeight 16; 
maxWidth -1; 
maxHeight := -1; 
type := ScreenFlagSet{ wbenchScreen] ; 
END; 
Window := OpenWindow(NuWindow) ; 
Assert (Window #NIL, ADR( “Shit! ”)); 


Read and Play Sound: 


Info := Read8SVX(Name, 16000, FALSE) ; (* load sound 


IF Info#NIL THEN 


IF OpenAudio(1,0) THEN (* open audio 


IF PlaySample(Info,Channel,65535,Channel) THEN END; 
VaitPort(Window .userPort); 


C1oseAudio(); (* close audio 
ELSE 
DigplayBeep(NIL) ; 
END; 
Dealloc8SVX(Info); (* free sound 
ELSE ^ 
DisplayBeep(NIL); (* error 
END; 


CloseWindow (Window) ; 


END PlayRep. 


Listing 4. 
Mit »PlayRep« wird der Sound endlos wiederholt 


rogram. PlayKeys.mod 
»Author. Fridtjof Siebert 
:Address. ^ Nobileweg 67, D-7-Stgt-40 
:Shorteut. + [fbs] 
Version. 1.0 
:Date. 19-Sep-88 
:Copyright. PD 
:Language. Modula-II 
:Translator. M2Amiga 
:Imports. IFF8SVXLoad [fbs], MemSystem [bne] 
:UpDate. none. 
Contents. Program to play a sampled Sound with different 


Listing 5. »PlayKeys« läßt das Sample in verschiedenen 
Tonhöhen erklingen 
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samplerates. 
:Remark. Usage: PlayKeys <iff-soundfile> 
--------------------------------------..---- nenn) 


MODULE PlayKeys; 


FROM SYSTEM IMPORT ADR, ADDRESS, SHIFT, BITSET, LONOSET, CAST; 


FROM Arts IMPORT Terminate, Assert; 

FROM Arguments IMPORT NumArgs, GetArg; 

FROM Dos IMPORT Delay; 

FROM Exec IMPORT GetMsg, WaitPort, ReplyMsg; 


FROM Intuition IMPORT DisplayBeep, NewWindow, WindowPtr, $ 
WindowFlags, 
WindowFlagSet, ScreenFlags, ScreenFlagSet, 
IDCMPFlags, IDCMPFlagSet, OpenWindow, 
CloseWindow, 
IntuiMessagePtr; 


FROM IFF8SVXLoad IMPORT Read8SVX, Dealloc8SVX, IFF8SVXInfoPtr, 
PlaySample, OpenAudio,: CloseAudio, WaitPlay, AllChannels; 


CONST 
ProgName = "PlayKeys, 1988 by Fridtjof Siebert [Amok]”; 


VAR 
Name: ARRAY[O..79] OF CHAR; (% the Sound's Name 
length: INTEGER; dummy for receiving Name's Length 
Info: IFF8SVXInfoPtr; Sound's Data 
Window: WindowPtr; 
NuWindow: NewWindow; 
Samples: CARDINAL; IFF's samplespersec 
s: LONGINT; My SamplesPerSec 
Msg: IntuiMessagePtr; 
Channel: CARDINAL; Active Channel 


BEGIN 


(ж - Get Name: -*) 


IF NumArgs() #0 THEN 
GetArg(1,Name,length); 
ELSE 
Terninate(0); 


Open Window: 


WITH NuWindow DO 

leftEdge :- 80; 

topEdge := 40; 

width t= 320; 

height := 80; 

detailPen:= 0; 

blockPen := 1; 

idempFlags := IDCMPFlagSet(closeWindow,vanillaKey] ; 

flags := WindowFlagSet{windowSizing, windowDrag, windowDepth, 
windowClose, activate] ; 


firstGadget := NIL; 

checkMark := NIL; 

title ADR(“Press some Keys !!!^); 
screen := NIL; 

bitMap := NIL; 

minWidth := 30; 

minHeight 


type := ScreenFlagSet{ wbenchScreen] ; 
END; 
Window := OpenWindow(NuWindow) ; 
Assert (Window #NIL,ADR( "Shit! ”)); 
Read and Play Sound: 
Info := Read8SVX(Name, 16000, FALSE) ; < (% load sound X) 


IF Info#NIL THEN 
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IF OpenAudio(4,0) THEN (* open audio ai 
Samples := Info .VHDR.samplesPerSec; 
Channel := 0; 


LOOP 
WaitPort(Window .userPort) ; 
Msg := GetMsg(Window .userPort) ; 
IF eloseWindow IN Msg’.class THEN EXIT END; 
s := LONGINT(Samples) * LONGINT(Msg’.code) DIV 64; 
ReplyMsg(Msg) ; ` 
IF (s<20000) AND (s>200) THEN 
Info’.VHDR.samplesPerSec :- в; 
IF NOT(PlaySample(Info,0,1,Channel)) THEN END; 
IF Channel<3 THEN 
INC(Channel); 
ELSE 
Channel:= 0; 
END; 
END; 
END; 
ReplyMsg(Msg) ; 


C1oseAudio(); (* close audio X) 
ELSE 


DisplayBeep(NIL); 
END; 


Dealloc8SVX(Info); (* free sound *) 


ELSE 
DisplayBeep(NIL); (% error x) 
END; 


CloselWindow(Window); 
END PlayKeys. 
Listing 5. (Schluß) 


:Program. PlayKanon.mod 
sAuthor. Fridtjof Siebert 
"Address, Nobileweg 67, D-7-Stgt-40 
:Shorteut. [fbs] 
Version. 1.0 
:Date. 19-Sep-88 
Copyright. PD 
Modula-II 
+ M2Amiga 
IFF8SVXLoad [fbs], MemSystem [bne] 
none. 
Contents. Program to play a sampled Sound on 4 times with 
0.55 delay. 


Usage: PlayKanon <iff-soundfile> 


MODULE PlayKanon; 

FROM SYSTEM IMPORT ADR, ADDRESS, SHIFT, BITSET, LONGSET, CAST; 
FROM Arts IMPORT Terminate; 

FROM Arguments IMPORT NumArgs, GetArg; 

FROM Dos IMPORT.Delay; 


FROM IFF8SVXLoad IMPORT Read8SVX, Dealloc8SVX, IFF8SVXInfoPtr, 
PlaySample, OpenAudio, CloseAudio, WaitPlay, AllChannels; 


CONST 
ProgName = “PlaySample, 1988 by Fridtjof Siebert [Amok] ”; 


VAR 
Name: ARRAY[O..79] OF CHAR; (% the Sound's Name 
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length: INTEGER; 
Info: IFF8SVXInfoPtr; 
1: CARDINAL; 


BEGIN 
Get Name: 
IF NumArgs() #0 THEN 
GetArg(1,Name, length); 


ELSE 
Terminate(0); 


Read and Play Sound: 


Info := Read8SVX(Name,20000, FALSE) ; 


IF Info#NIL THEN 


IF OpenAudio(4,0) THEN 


(* dummy for receiving Name's Length X) 
(* Sound's Data ж) 


(% load sound *) 


(* open audio *) 


FOR i:=0 70 3 DO 


IF PlaySample(Info,0,1,1) THEN 


Delay(25); 
END; 
END; 
WaitPlay(AllChannels); 


Delay(100); 


FF 


(* play sound *) 


(% wait 28 to get last samples before 


closing audio *) 


CloseAudio() ; 
END; 
Dealloc8SVX(Info) ; 

END; 


END PlayKanon. 


(* elose audio *) 


(* free sound *) 


Listing 6. Das Demo »PlayKanon« aktiviert alle vier 


Soundkanäle 


Für Programmierer: das IFF-Grafik-Format 


Der Standard 


Nichts hat sich so 
durchgesetzt wie 
das IFF-Format auf 
dem Amiga. Wir 
verraten Ihnen, was 
Sie als Programmie- 
rer bei der Arbeit 
mit IFF-Grafikdatei- 
en wissen sollten. 


Von Fridtjof Siebert 
und Martin Jobst 


ast jeder Computer- 
Anwender kennt das 
Problem: Programm x 


kann die Daten von Programm 
y nicht verarbeiten. Wenn über- 
haupt, machen erst mühselige 
Konvertierungen die Verarbei- 
tung móglich. Amiga-User ha- 
ben es da besser. Bereits seit 
den Urzeiten des Amiga exi- 
stiert das von Electronic Arts ins 
Leben gerufene IFF-Format (In- 
terchange File Format). Es ver- 
einfacht den Austausch von 
Grafik- genauso wie von 
Sound- oder Animations-Da- 
teien. Gerade als Programmie- 
rer sollten Sie über dessen Auf- 
bau genau Bescheid wissen. 
Wir geben Ihnen daher im fol- 
genden eine genaue Beschrei- 
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schreibung der Struktur des 
IFF-Bildformats. 

IFF-Dateien beginnen mit der 
Kennung »FORM«. Darauf folgt 
die Länge des Datenblocks. 
Dieser enthált die Kennung der 
Daten, welche bei Bildern 
»ILBM« ist. Dahinter liegen be- 
liebig viele Datenblócke, wel- 

che jeweils mit vier Byte begin- 

nen. Diese kennzeichnen die 
Daten. Darauf folgt ein Lang- 
wort, das wiederum die Lánge 
des Datenblocks angibt. Den 
genauen Aufbau einer ILBM-Da- 
tei entnehmen Sie bitte Tabelle 
1. »Byte« ist die Nummer des je- 
weils beschriebenen Bytes. 


` 464F524D 0000567A 494C424D 


: 00000014 014000С8 
: 00020A0B 014000С8 
: 00000090 10000000 
: 10305010 40602050 
: 70806070 C07080D0 
: F06020D0 50208040 
: 20103000 00000080 
: A00000A0 0000A000 
: 44505056 00000068 
: 01680000 014000С8 
: 00020000 00020000 
: 00000000 00000000 
: 00000000 00000000 
: 00000000 00000000 
: 00000000 00000000 
: 4352447 00000008 
: 43524647 00000008 
: 43524E47 00000008 
: 43524E47 00000008 
: 424F4459 00005539 
: DCC00000 01610000 
: 03ҒЕ0004 В5С0С890 


00000000 
43404150 
00200020 
70305080 
9090E0A0 
10903010 
0000A000 
00A00000 
00000000 
0002005A 
00000000 
00000000 
00000000 
00000000 
00000000 
19961800 


29304E78 
DD41AB4A 
0047ҒЕҒ4 
11043336 
FFFFAOF9 
ETFEO011 


Der Block »BMHD« bildet die 
Basis einer IFF-Grafik und ent- 
hált wichtige Daten, wie die 
GróBe des Bildes oder die An- 
zahl der Bitplanes. »CMAP« 
legt die Farben fest, wáhrend 
»GRAB« die Móglichkeit bietet, 
einen bestimmten Punkt (»hot 
spot«) der Grafik zu markieren. 

»DEST« gibt an, in welche Bit- 
planes die Grafikdaten ge- 
Schrieben werden. Im Block 
»CAMG« werden besondere 
Modi wie Interlace, HAM etc. 
festgelegt. »CRNG« dient zur 
Steuerung einer Farbanima- 
tion, »BODY« schlieBlich enthált 
die eigentlichen Daten der Gra- 


42404844 
05020100 
00000060 
30003040 
4060A050 
AOFOCOCO 
60301040 
00A00000 
A00000A0 
00000000 
00020000 
00000000 
00000000 
00010002 
00010002 
00010002 
0002020F 
00039026 
FFFFFFF7 
00000001 
O1EFDC3F 
00026130 
FDC337FF 


Bild 1. Beispiel einer IFF-Lores-Grafik als Hex-Dump 


fik und ist damit zusammen mit 
»BMHD« zwingender Bestand- 
teil eines IFF Grafik-Files. 

Ein Ladeprogramm für IFF- 
Bilder sollte Daten, die unbe- 
kannte Kennungen haben, ein- 
fach überlesen. Die Lange die- 
ser Daten steht jeweils im dar- 
auf folgenden Langwort. Einen 
unbekannten - oder besser: 
nicht benötigten - Datenblock 
finden Sie beispielsweise am 
Ende von Tabelle 1 unter dem 
Namen »CMHD«. Dieser wird 
vom Programm »Graphiccraft« 
verwendet. 

Ein gültiges ILBM-File muß 
die Blöcke »BMHD« und »BO- 
DY« enthalten, »CMAP« sollte 
vorhanden sein. Alle anderen 
Strukturen sind optional. In Bild 
1 sehen Sie ein Beispiel für eine 
Lores-Grafik mit der Auflösung 
320 x 200 (14H: 0140Н; 16H: 
0C8H) als Hex-Dump. Die Tiefe 
beträgt 5 Bitplanes (1CH), des- 
halb besteht sie aus 32 Farben 
(in 2CH steht 60H, durch 3 also 
20H32). Die Daten in »DPPV« 
sollten überlesen werden. Die 
vier »CRNG«-Blöcke sind eben- 
falls meist unwichtig. so 


Martin Jobst studiert Publizistik und Kommuni- 
kationswissenschaft in Salzburg und arbeitet 
seit drei Jahren als freier Mitarbeiter für Zeit- 
schriften des Markt&Technik Verlages. Sie 
kónnen ihn erreichen über unsere Verlagsan- 
schrift (Markt& Technik Verlag AG, Redaktion 
Sonderhefte, z. Hd. Martin Jobst, Hans-Pinsel- 
StraBe 2, 8013 Haar). 
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Bezeichnung Funktion 


"GRAB", hot spot: 


Byte 


"FORM" 
LONGCARD 


"ILBM^ 


Unterblock 1 


kennzeichnet IFF-Datei 
Lánge des Datenblocks, entspricht der 


Filelánge 8, da die Daten beim achten 
Byte beginnen 


kennzeichnet die Grafikdatei 


(Interleaved BitMap) 


Unterblock 2 


etc. 


Bezeichnung 


die verschiedenen Daten 


Funktion 


0 "GRAB" 
4 LONGCARD(4) 
8 INTEGER(x) 


10 INTEGER(y) 


Kennung 

Lange 4 Byte 

x-Position des markierten 
Punktes 

y-Position 


” DEST” , destination: 


"BMHD”, BitMapHeader: 


"BMHD 
LONGCARD(20) 
CARDINAL(dx) 
CARDINAL(dy) 
INTEGER(x) 
INTEGER(y) 
UBYTE(Depth) 
UBYTE(Masking) 


UBYTE 
(Compression) 
UBYTE(0) 
CARDINAL(trans- 
parentColor) 
UBYTE(xAspect), 
UBYTE(yAspect) 


INTEGER(dx) 
INTEGER(dy) 


Kennung des Blocks 

Lange der Daten: 20 Bytes 

Breite der Grafik 

Hohe der Grafik 

x-Position der Grafik (LeftEdge) 
y-Position der Grafik (TopEdge) 
Anzahl der Bitplanes 

Maske für Grafik, normalerweise 
nicht vorhanden (0). 

1: Maske vorhanden, in diesem Fall 
enthält “BODY” eine zusätzliche 
Bitplane mit der Maske, diese muß 
dann auch geladen werden. 

2: Durchsichtige Farbe, es steht in 
»TransparentColor« eine 
Farbnummer, die als durchsichtig 
gelten soll. 

3: Eine Maske kann erzeugt 
werden, indem man eine Art Lasso 
um das Image wirft. Dazu zieht 
man eine Linie außen um das Bild 
und füllt den Innenraum mit 
»transparentColor« aus. Alle 
Punkte, die daraufhin die Farbe 
»transparentColor« verwenden, 
werden »durchsichtig«. 

0: Daten nicht gepackt 

1: Daten gepackt, siehe "BODY" 
nicht benutzt, muB 0 sein 
durchsichtige Farbe, siehe 
»Masking« 

Verzerrung des Bildes, bei einer 
Auflósung von 320x200 im 
Verháltnis 10:11 

Breite des Screens 

Hóhe des Screens 


"DEST" 
LONGCARD(8) 
UBYTE(Depth) 
UBYTE 
CARDINAL 
(PlanePick) 
CARDINAL 
(PlaneOnOff) 
CARDINAL 
(PlaneMaks) 


Kennung 

Lange 

Anzahl der Planes in Quell-Grafik 
Füllbyte: 0 

siehe Intuition Ref. Manual, 
5.192 ff 


zum Schreiben benutzte Bitplanes 


"CAMG", besondere ViewModes: 


0 "CAMG" 

4 LONGCARD(4) 

8 LONGSET 
(ViewMode) 


entspricht nicht »ViewModeSet{]« 
(2): Interlace 

{10}: DoublePlayField 

[17]: Hold and Modify 

(31): HiRes 


"CRNG”, Colorcycling: 


"CRNG" 
LONGCARD(8) 
INTEGER 
INTEGER(rate) 


INTEGER 
UBYTE(low) 
UBYTE(high) 


nicht benutzt: 
Geschwindigkeit: 
60mal/s=8000H 
30mal/s=4000H 
1mal/ec- 8000H 
eingeschaltet: ungleich 0 
unterste und 
oberste Grenze der Farbe 


"BODY", enthält die eigentlichen Bilddaten: 


“CMAP”, ColorMap: 


0 
4 


"CMAP" 
LONGCARD(x) 


UBYTE(Red) 
UBYTE(Green) 
UBYTE(Blue) 
UBYTE(Red) 
etc. 
UByte(Blue) 


Kennung des Blocks + 
Länge des Blocks, entspricht der 
Anzahl der Farben geteilt durch 
drei. Für gewöhnlich ist die Anzahl 
der Farben eine gerade Zahl, 
weshalb kein Füllbyte eingefügt 
werden muß. 

Rotanteil Farbe 0 

Grünanteil Farbe 0 

Blauanteil Farbe 0 

Rotanteil Farbe 1 


Blauanteil Farbe (x DIV 3) 


"BODY" 
LONGCARD(x) 
Daten 


Länge (Hóhe* Breite * Tiefe/8) 

wenn in "BMHD" »Compressed« 
gewählt wurde, in gepacktem 
Format. 

Ungepackte Bitmap-Daten; Daten 
sind der Reihe nach gespeichert:1. 
Zeile, 1. Bitplane; 1. Zeile 2. 
Bitplane etc. Danach: 2. Zeile 1. 
Bitplane, 2. Zeile 2. Bitplane etc. 
Gepackte Bitmap-Daten: gepackt 
wird nur innerhalb einer Zeile. Die 
Zeilen sind der Reihe nach (analog 
wie bei den ungepackten Daten) 
gespeichert. Gepackt wird 
byteweise: Liegt ein Byte im 
Bereich von 0 bis 127, bedeutet 
das: die náchsten n--1 Bytes 
unverándert in die Grafik laden. 
129 bis 255 heiBt: das folgende 
Byte wird 257-n Mal hintereinander 
in die Grafik kopiert. 128: 

keine Funktion. 


Weitere Datenblócke: 


"SPRT” 
"CCRT^ 
"CMHD^ 
"DPPV^ 


für Sprites 


Tabelle 1. Die Struktur eines IFF-Grafik-Files mit den einzelnen Unterblócken 
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Graphiccraft: Colorcycling 
Graphiccraft (?) 
Graphiccraft (?) 
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U BERBLICK 


Gängige Spielearten für den Amiga 


Spiele und kein Ende 


С: sind universel- 

С: Werkzeuge. Erledi- 

gen sie für den Anwen- 
der vor allem nützliche Aufga- 
ben, sind sie auch für andere 
Bereiche wie geschaffen: Spie- 
le.. Gerade der Amiga - ur- 
sprünglich als reine Spielma- 
schine konzipiert - ist ideal für 
diesen Zweck. Wir haben ver- 
sucht, die gángigen Spiele grob 
nach Genres einzuteilen, um 
Ihnen einigermaBen Überblick 
zu verschaffen. Reprásentative 
Vertreter werden dabei genau- 
so genannt, wie Reiz und we- 
sentliche Elemente der ver- 
schiedenen Gattungen. 


Adventures 


Die Abenteuerlust im Com- 
puter. Sie sind der Held - oder 
Antiheld - der sich durch eine 
Welt jenseits von Gut und Böse 
schlagen muß. Sie kämpfen mit 
realen oder irrealen Proble- 
men. Manchmal brennt der 
Hut, ein anderes Mal ist High- 
Life angesagt. Fast wie im rich- 
tigen Leben. 

Abenteuerspiele faszinieren 
durch die große Abwechslung, 
die sie dem Spieler bieten. Wie 
Sie das Abenteuer überstehen, 
hängt von Ihrer Kreativität, Ih- 
rem Ehrgeiz und Forschergeist 
ab. Mittels eines sogenannten 
Parsers teilen Sie dem Compu- 
ter Ihre Entscheidungen mit. 
Wie gut dieser Parser Sie ver- 
steht, hängt stark davon ab, ob 
Sie ein Text- oder ein Grafik-Ad- 
venture spielen. 

Text-Adventures arbeiten rein 
auf Textbasis und mit Ihrem Vor- 
stellungsvermögen. Sie be- 
kommen die Informationen 
über Ihre Umgebung nur verbal 
mitgeteilt, erhalten detaillierte 
Schilderungen der Welt im 
Computer. Genauso detailreich 
können Sie dem Computer Ihre 
Vorstellungen und Anweisun- 
gen mitteilen. Text-Adventures 
besitzen sehr gute Parser und 
verstehen - zwar meist in Eng- 
lisch - auch komplexe Sätze. 
Ungeschlagen in diesem Gen- 
re sind immer noch die Adven- 
tures von Infocom. »Hitchhikers 
Guide to the Galaxy« etwa faszi- 


AMIGA-SONDERHEFT 7 


Der Spieltrieb des Menschen ist unersätt- 
lich. Selbst vor Computern macht er nicht 
halt. Was haben diese Maschinen zu bieten? 


Von Martin Jobst 


niert durch Detailreichtum und 
seine spritzige Art. 

Grafik-Adventures haben op- 
tisch wesentlich mehr zu bie- 
ten. Der Amiga als prädestinier- 
te Grafikmaschine ist für diese 
Art Spiele besonders geeignet. 
»Fish« oder »The Pawn« von 
Magnetic Scrolls sind gute Bei- 
spiele für Grafik-Adventures auf 
dem Amiga. Mit einer Unmen- 
ge an schönen Bildern verwöh- 
nen sie den Spieler und lassen 
ihn mit der Computerwelt eins 
werden. Der Nachteil bei dieser 
Art Abenteuer liegt meist am re- 
lativ schlechten Parser. Durch 
den großen Speicherbedarf der 
Grafiken, bleibt für die Schnitt- 
stelle Mensch-Computer oft we- 
nig Platz. 


Rollenspiele 


Stark verwandt mit den Ad- 
ventures ist die nächste Gat- 
tung: die Rollenspiele. Sie be- 
finden sich auch hier in einer in 
Silikon geformten Welt und 
kämpfen ums Überleben. Im 
Unterschied zu den Abenteuer- 
spielen kommt es aber hier stär- 
ker auf Ihre Person an, auf die 
Person, die Sie im Computer 
verkörpern. Wie der Name 
schon sagt, nehmen Sie be- 
stimmte Rollen ein: als Zaube- 
rer, Gnom oder was auch im- 
mer. Jedenfalls ist Gedeih oder 
Verderb stark von den Eigen- 
schaften abhängig, die Sie be- 
sitzen oder sich im Laufe des 
Spieles - wie auch immer - an- 
eignen. Stark abhängig sind 
Sie auch von Ihren Komparsen 
samt deren Eigenschaften. Nur 
wenn Sie diese geschickt aus- 
wählen, haben Sie auch Chan- 
cen, zu überleben. 

Rollenspiele arbeiten wie 
Grafik-Adventures stark mit gra- 
fischen Elementen. Wieder 


können wir zwei Gattungen un- 
terscheiden. Während Rollen- 
spiele wie »Bard’s Tale« stark 
mit symbolischen Mitteln arbei- 
ten, haben Sie Kämpfe und an- 
dere Aktionen bei »Dungeon 
Master« in »Realtime« auszutra- 
gen. Geben Sie acht, daß Sie 
Ihre Rolle nicht ins richtige Le- 
ben mitnehmen: »Nein, glau- 
ben Sie mir, Sie sind kein Zau- 
bererl« 


Strategiespiele 


Taktik ist gefragt. Auch wenn 
Sie Strategiespiele auf dem 
Computer spielen, kommen Sie 
um das Kopfzerbrechen nicht 
herum. Der Sinn, diese Art von 
Spielen auf Rechnern zu spie- 
len, ist der fehlende Partner, 
den diese Ihnen ersetzen kön- 
nen. Nicht nur das, starke Pro- 
gramme stellen Gegner, die Sie 
- was die Spielstärke betrifft - 
sonst nicht so schnell finden. 
Sie kónnen.auf dem Amiga jede 
Menge spielen: ob Dame, 
Schach, Knobelspiele oder chi- 
nesische Brettspiele - alles ist 
möglich. 

Besonders interessant sind 
natürlich Schachprogramme. 
Wenn Sie das spielstärkste su- 
chen, ist Ihnen mit »Collossus 
Chess X« gedient. Das Pro- 
gramm ist erst seit kurzem auf 
dem Markt, schlägt aber seine 
Konkurrenten bei weitem. Ganz 
nett, was die Optik betrifft, ist 
auch »Battle Chess«. Der Reiz 
dieser Schachvariante liegt 
darin, daß alle Züge als Kämpfe 
ausgetragen werden, die 
prächtig animiert auf dem Bild- 
schirm dargestellt werden. Was 
dieses Programm allerdings 
nicht kann, ist Schachspielen. 
Wenn Sie einen kompetenten 
Gegner suchen, ist Ihnen mit 
diesem Programm keinesfalls 
geholfen. 


Ein Brettspiel, das Sie vor 
den Monitor fesseln wird, ist 
»Shanghai«. Bei der Variante ei- 
nes chinesischen Brettspiels, 
geht es darum, von Türmen aus 
Spielsteinen nach bestimmten 
Regeln immer zwei gleiche 
wegzunehmen. Hört sich ein- 
fach an? Ist es aber ganz be- 
stimmt nicht. Der Computer ist 
bei diesem Spiel nicht Ihr un- 
mittelbarer Gegner, er ersetzt 
nur das Spielbrett und legt die 
Spielsteine auf. 


Sportspiele 


Tor! Tor! Tor! So klingt es nicht 
nur zuzeiten von Fußballmei- 
sterschaften aus Ihrem Fern- 
sehlautsprecher. Auch Ihr Ami- 
ga kann da mithalten. Fußball- 
simulationen wie »Kick off« ho- 
len den Ball auf den Bildschirm. 
Aber warum Sport auf dem 
Computer? Das kann viele 
Gründe haben. Aber ob nun 
aus Faulheit, Bequemlichkeit 
oder schlicht schlechtem Wet- 
ter vor der Tür, Sport ist auch 
auf dem Computer sehr reiz- 
voll. Gerade dann, wenn Sie 
das Vergnügen mit einem Part- 
ner teilen und gegeneinander 
zur Eishockey-Weltmeisterschaft 
antreten. Und von wegen un- 
sportlich: passen Sie auf, daB 
Sie sich beim Body-Check auf 
dem Schirm Ihre Finger nicht 
verrenken. 

Auch bei diesem Genre grei- 
fen die tollen Grafikfáhigkeiten 
unseres Amiga. Sportspiele 
stehen und fallen mit der Reali- 
tátsnáhe der grafischen Dar- 
stellung. Daher kann man Spie- 
le wie »Kick off« fast schon als 
Simulationen bezeichnen. 
Auch futuristische  Ballspiele 
wie »Ballistix« oder »Speed- 
Ball« üben groBen Reiz aus. 
Wenn Sie's amerikanisch wol- 
len: »California Games« von 
Epyx, zeigt die sportliche Reali- 
tátan den Stránden Kaliforniens. 


Lange Zeit schauten Amiga- 
User neidisch auf Spielautoma- 
ten oder Besitzer von Video- 
Spiel-Konsolen. Die Mißgunst 
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richtete sich auf die tollen 
Renn-Spiele, die es für diese 
Geräte gab. Daß diese Zeiten 
endgültig vorbei sind, bestäti- 
gen eine Reihe von Neuer- 
scheinungen für den Amiga. 

Wettrennen im Computer, mit 
schneller Grafik und noch 
schnelleren Boliden - reizvoll 
für viele. Wettrennen auf unse- 
ren Straßen mit schnellen Autos 
und noch größerem Risiko - 
tödlich für viele. Dann doch lie- 
ber der Crash im Computer. 

Geben Sie Ihrem Drang nach 
schnellen Fahrzeugen nach 
und erleben Sie einen Ge- 
schwindigkeitsrausch - vor Ih- 
rem Computer. Rasen Sie bei 
»Super Hang On« mit einem 
schnellen Motorrad über Grand- 
Prix-Strecken dieser Welt und 
riskieren dabei nicht Ihr Leben. 
Machen Sie mit »Crazy Cars Ile 
amerikanische High-Ways un- 
Sicher und finden Sie den Weg 
gen Süden. Brausen Sie in 
»Stunt Car Racer« auf achter- 
bahn-máBigen Strekken und 
schlagen Sie Ihren Gegner. Er- 
geben Sie sich dem Gefühl von 
Freiheit und Schnelligkeit - 
hautnah und rasend schnell, 
aber dennoch risikolos und 
preiswert: der Ferrari, den Sie 
mit »Crazy Cars Il« erwerben, 
kostet Sie 0,01 Prozent des rea- 
len Vorbilds... 


Simulationen 


Die Realität in ihre Kiste zu 
verfrachten - kein unbekannter 
Traum für viele Computer- 
Freaks. Der Wunsch nach Si- 
mulation von realen oder fikti- 
ven Vorgángen ist prásent. 
Klassisch und zugleich aktuell 
ist die Umsetzung eines al- 
ten Menschheitstraums,. des 
Traums vom Fliegen. Bereits zu 
ihren Urzeiten erhoben sich 
Computer in die Lüfte. Unter 
mehr oder minder realen Be- 
dingungen steuert man ein 
Flugzeug durch die Wolken. 

Klassisch und zugleich et- 
was veraltet ist der »Flight Il«. 
Unter lebensnahen Umstánden 
fliegen Sie mit einem Sportflug- 
zeug der Sonne entgegen. So 
realistisch die Bedingungen 
auch sein mógen, die langsa- 
me Grafik läßt verwóhnte Ami- 
ga-Fans schnell ermüden. Flot- 
ter geht's da schon bei »Inter- 
ceptor« zu: rasende Flüge mit 
einem amerikanischen Kampf- 
flugzeug. Abgedroschener da- 
für leider das Ziel des Spieles: 
die Jagd nach russischen Flug- 
zeugen vom Typ MIG 13. 

Wesentlich anspruchsvoller 
geht es dagegen bei »Ports of 
Call« zu. Sie sind Reeder, und 


136 


müssen sich vor geldgierigen 
Konkurrenten hüten. Halten Sie 
Ihre Flotte dicht und lassen Sie 
sich nicht beim Schmuggeln er- 
wischen. Eine Wirtschaftssimu- 
lation, die es in sich hat. Ken- 
nen Sie schon die Preise für die 
neuen Schiffe mit 10000 Brutto- 
registertonnen? 


Breakout-Spiele 


Fang den Ball! Alles was Ih- 
nen dazu zur Verfügung steht, 
ist ein kleiner Schläger. Ein ein- 


faches, aber fesselndes Spiele- 
prinzip. Entstanden aus dem 
Ur-Klassiker der Computer- 
spiele bieten Breakout-Varian- 
ten auf dem Amiga dem Spieler 
viel Abwechslung. 

Die verschiedenen Gim- 
micks wie Klebstoff-Schläger, 
Laser, mehr Bälle und die be- 
stechende Grafik schalten Di- 
stanz zum Klassiker - und Ab- 
wechslung. Die Spitzenreiter 
Sind »Arkanoid Il« und »Crystal 
Hammer, 

Laufen, hüpfen, sammeln. 


Jump'n Run- 
Spiele 


Das ist in gebotener Kürze das, 
was bei diesen Spielen ange- 
sagt ist. Durchstöbern Sie Level 
für Level nach wichtigen Ge- 
genständen und treten Sie 
nicht in diese oder jene Falle. 
Waren auf einem C64 Affen 
wie »Donkey Kong« die Stars, 
geht's auf dem Amiga schon 
wesentlich »gewichtiger« zu. 
»Hard'n Heavy« ist wohl aussa- 


Vermarktungsstrategien für Spiele 


Sie haben ein Spiel 
programmiert und 
wollen es an den 
Mann/die Frau 
bringen. Wir zeigen 
Ihnen den ersten 
Schritt auf dem 
Weg zum Erfolg. 


Von Martin Jobst 


in Spiel sauber zu pro- 

grammieren ist eine Sa- 

che, es erfolgreich zu 
vermarkten eine andere. Sie in- 
vestieren viel Zeit, Arbeit und 
nicht zuletzt Nerven in Ihr Pro- 
jekt. Wie hoch das letztlich ho- 
noriert wird, hángt stark davon 
ab, welchen Weg Sie zur Ver- 
marktung Ihres Spiels be- 
schreiten. Sie sollten daher al- 
les daran setzen, das Beste aus 
Ihrer Arbeit zu machen. Dazu 
müssen Sie nur Móglichkeiten 
finden, Ihr Produkt - im buch- 
stáblichen Sinne - richtig zu 
verkaufen. Viele Wege führen 
dahin und sicherlich gibt es kei- 
nen, der immer gültig wáre. Wir 
wollen Ihnen einige Tips geben 
und einen möglichen Weg zei- 
gen, wie Ihr Produkt den Weg 
auf die Ladentische der Soft- 
ware-Händler findet. 

Wenn Sie Empfehlungen su- 
chen, wie man ein Spiele- 
Projekt von der Programment- 
wicklung her am besten durch- 
zieht, lesen Sie unseren Beitrag 
dazu ab Seite 6. 

»Viele Kóche verderben den 
Brei« lautet ein altes Sprich- 
wort. DaB es sich bei der Pro- 
grammentwicklung nicht so 
verhält, ist längst bewiesen: die 
meisten guten Programme ent- 
stehen aus der Zusammenar- 
beit von Teams. Daß Ihnen als 


Von der 


»kleiner« Programmierer keine 
Crew aus Grafikern, Designern 
und Musikern zur Verfügung 
steht, ist uns schon klar. Was 
wir damit sagen wollen ist nur, 
daß gute Programme meist 
nicht in einem Kopf entstehen. 
Auch wenn Sie Ihr Spiel alleine 
programmieren, sollten Sie es 
vor der endgültigen Fertigstel- 
lung möglichst vielen Leuten 
zugängig machen. 

Versuchen Sie daher, Vorver- 
sionen Ihres Spiels unter die 
Freaks zu bringen. Zehn Leute 
finden schneller die Bugs in ei- 
nem Programm, zehn Leute ha- 
ben mehr Ideen für Verbesse- 
rungen, zehn Leute können 
mehr aus Ihrem Spiel machen. 
Tja, aber: wie finde ich die zehn 
Leute, die sich für mein Pro- 
gramm interessieren, es auf Feh- 
ler testen etc.? Nicht nur zehn, 
hundert, ja tausend Freaks, die 
Ihr Programm liebend gerne te- 
Sten und auseinandernehmen, 
lassen sich jederzeit finden. 
Wo? Im PD-Pool. Etwas Besse- 
res kann Ihrem neuen Spiel gar 
nicht passieren, als (in einer 
Vorversion) über PD verbreitet 
zu werden. Sie glauben gar 
nicht, welche Vorteile sich dar- 
aus ergeben. Achten Sie dabei 
aber wirklich darauf, nur eine 
Demo-Version über PD zu ver- 
breiten, wenn Sie beabsichti- 
gen, das Programm später 
noch kommerziell zu vermark- 
ten. Bauen Sie also »Sperren« 
ein, die das Programm nur be- 
dingt nutzbar machen. Der 
Zweck soll ja nur sein, die we- 
sentlichen Elemente des Pro- 
grammes zu demonstrieren. 

Ganz abgesehen davon, daß 
móglichst viele Freaks auf Ihr 


Produkt aufmerksam werden 
und potentielle Kunden für das 
»Endprodukt« sein kónnen, er- 
halten Sie von diesen bestimmt 
auch eine Menge Anregungen. 
Wo Bugs in Ihrem Programm 
sind, was verbessert werden 
sollte und was daran toll ist, er- 
fahren Sie dann als Reaktion 
von Anwendern oder besser 
»Spielern«. DaB Sie sich ganz 
nebenbei in der Szene einen 
Namen machen kónnen, ist ein 
angenehmer Nebeneffekt. Viele 
Beispiele geben Zeugnis dafür. 
Warum etwa arbeitet ein Leo 
Schwab plötzlich bei einer Walt 
Disney-Software-Produktion na- 
mens »Roger Rabbit« mit? 
Richtig geraten, weil die Szene 
ihn über PD durch seine wun- 
derbaren Grafik-Demos kennt. 

Vielleicht wird eine Software- 
Firma über PD auf Ihr Produkt 
aufmerksam und interessiert 
sich für dessen Endversion. 
Daß Ihre Arbeit finanziell dann 
besser belohnt werden wird, 
liegt auf der Hand. Erstens kön- 
nen Sie mit der: Vorversion in 
der Hand womöglich einen bes- 
seren Vertrag abschließen. 
Zweitens erfahren Sie vielleicht 
durch das Software-Haus Un- 
terstützung bei der Weiterent- 
wicklung Ihres Produktes. 

Ein anderer Weg, mit der 
Vorab-Version Ihres Spieles ei- 
ne möglichst große Gruppe an- 
zusprechen, wäre der Weg 
über die Veröffentlichung in ei- 
nem Computer-Magazin. Auch 
hier sind Ihnen die Reaktionen 
vieler User sicher und auch 
Kontakte zu Produzenten könn- 
ten sich so ergeben. Ganz ne- 
benbei könnten Sie sich auch 
gleich ein paar Mark verdienen, 
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gekräftig genug für ein Spiel ei- 
ner neuen Generation dieses 
Genres. Kämpfen Sie sich 
durch 24 mit Gegnern gespick- 
ten Levels und hüten Sie sich 
vor herumschwirrenden Gru- 
selviechern. Sammeln Sie so- 
viel Sterntaler wie möglich und 
lassen Sie sich nicht von getarn- 
ten Schatzkammern verlocken. 


Ping, Peng, Pong, Knatatata- 
ta. Ballern und kein Ende: das 


Idee zum Erfolg 


die Sie in die Weiterentwicklung 
Ihres Produktes investieren 
kónnen, die Sie aber zumindest 
anspornen werden. 

Wie Sie Ihr Spiel auch reifen 
lassen mógen, früher oder spá- 
ter wird es zur Vertragsanbah- 
nung mit einem Softwarehaus 
kommen. Bevor es aber so weit 
ist, sollten Sie als ersten Schritt 
mit allen in Frage kommenden 
Partnern Kontakt aufnehmen. 
Informieren Sie sich über deren 
Angebote und lassen Sie sich 
konkrete Honorarvorschläge 


Motto unseres letzten Genres. 
Fast so alt wie der Computer 
selbst, bieten diese Spiele im- 
mer Unglaublicheres. Begann 
al-les mit einfachen Space In- 
vader-Varianten, haben heutige 
Klasse-Spiele nur noch das Prin- 
zip mit den Ahnen gemeinsam. 
Sie führen den Spieler in neue 
Welten und holen grafisch das 
Letzte aus dem Amiga heraus. 

Der Weltraum-Commander 
fliegt durch bizzare, futuristi- 
sche Landschaften, ballert mit 
unglaublichen  Laser-Phasern 


geben. Nur so kónnen Sie den 
Marktwert Ihres Spiels heraus- 
finden und das beste Angebot 
erkennen. 

Seien Sie mit Umsatzbeteili- 
gungen vorsichtig. Ansonsten 
kann der Deal mit Ihrem Spiel 
sehr schnell selber zu einem 
solchen werden - Kategorie 
Glücksspiel. Besteht das zu er- 
wartende Honorar zum Großteil 
aus Umsatzerlósen, stehen Sie 
sehr schnell mit leeren Hánden 
da. Bedenken Sie auch, daß 
Sie die verkauften Stückzahlen 


Usersuck 


durch die Gegend und hat ge- 
gen Wesen der fünften bis ach- 
ten Art anzukämpfen. »Kata- 
kis«, »Hybris«, »Menace«, »R- 
Type«: das sind die High-Lights 
unter den Ballerspielen. Ideale 
Games, um den Alltagsstreß 
hinter sich zu lassen und ein- 
mal so richtig reinzuhauen. 
Sie meinen, unsere Über- 
sicht wäre nicht vollständig? 
Sie haben recht. Um alle Spie- 
learten für den Amiga vollstän- 
dig zu erfassen, wären etliche 
Kategorien mehr nötig. Wir ha- 


selbst nie wirklich kontrollieren 
können. Sie sind dabei zum 
großen Teil auf die Seriosität 
des Softwarehauses angewie- 
sen. In untenstehendem Ka- 
sten finden Sie noch einige 
Tips, wie Sie negative Erlebnis- 
se vermeiden können, Tips von 
Leuten, die in diesem Bereich 
bereits Erfahrung gesammelt 
haben. 

Universallösung für die Ver- 
marktung eines Programms 
gibt es keine, dazu sind die Vor- 
aussetzungen von Fall zu Fall 


ben nur versucht, die größten 
Bereiche zu erfassen. So gibt 
es viele Spiele, die aus dem 
Rahmen fallen und eine eigene 
Sparte bilden würden. Wir den- 
ken dabei etwa an Tetris & Co. 
Viele Spiele schienen uns aber 
auch dank ihrer subtilen Hand- 
lung nicht erwähnenswert: 
Denken Sie etwa an Ballereien 
im Rambo-Stil. Andere Genres 
beginnen sich erst zu bilden. 
Vielleicht setzen Sie mit Ihrem 
nächsten Spiel einen neuen 
Meilenstein? so 


zu verschieden. Beachten Sie 
aber unsere Tips und Hinweise, 
wird es Ihnen gelingen, Ihr 
Spiel nach Ihren Vorstellungen 
vermarkten zu können - Erfolg 
damit zu haben. so 


Martin Jobst studiert Publizistik und Kommuni- 
kationswissenschaft in Salzburg und arbeitet 
seit drei Jahren als freier Mitarbeiter für Zeit- 
schriften des Markt&Technik Verlages. Sie 
können ihn erreichen über unsere Verlagsan- 
schrift (Markt & Technik Verlag AG, Redaktion 
Sonderhefte, z. Hd. Martin Jobst, Hans-Pinsel- 
Straße 2, 8013 Haar). 


Profis geben Tips 


Grundsätzliches zur Vermarktung: 

- Es ist nur dann zu empfehlen, ein Spiel kommerziell (also über ein 
Softwarehaus) zu vermarkten, wenn die Honorare, die Sie erwarten 
kónnen, die 10000-DM-Grenze überschreiten. Andernfalls ist es sinn- 
voller, zu versuchen, das Produkt über eine Zeitschrift (etwa als Pro- 
gramm des Monats) zu verwerten. Es fállt dann der betráchtliche Auf- 
wand, der Ihnen mit einem professionellen Projekt entsteht, weg. Al- 
lerdings können Sie nur mit einem Honorar von höchstens 2000 DM 
rechnen. 

- Überlegen Sie sich, bevor Sie an entsprechende Softwareháuser 
herantreten, für welchen Markt Ihr Produkt eigentlich geeignet ist. 

- Aus Copyright-Gründen sollten Sie darauf achten, ob nicht bereits 
ein Produkt auf dem Markt ist, das den gleichen Namen trágt wie Ihr 
Spiel. 

- Bevor Sie einen Vertrag mit Ihrem Partner anbahnen, sollten Sie 
Sich unbedingt von dessen Seriositát überzeugen. Schwarze Schafe 
gibt es in diesem Markt genug. Oft fehlt diesen - meist Kleinstfir- 
men - das nótige Kapital und auch das Know-how für den Vertrieb 
Ihres Produkts. So mancher dieser Verlage versucht nur eine schnelle 
Mark zu machen - auf Ihre Kosten. Sehr schnell stehen Sie mit leeren 
Händen da. Im Extremfall verlangt man von Ihnen sogar Zahlungen, 
für den Verlust, den Ihr Produkt verursacht... 

Viele Programmierer fallen dann auf unserióse Anbieter herein, 
wenn sie von größeren Häusern Absagen erhalten und nach neuen 
Wegen suchen, Ihr Produkt zu vertreiben. Oft ist aber dann der Weg 
über eine Veróffentlichung in einer Zeitschrift der günstigere. 


Der Vertrag: 
Wenn es soweit ist und der VertragsabschluB kurz bevorsteht, soll- 
ten Sie den Vertrag inhaltlich genau prüfen. Achten Sie auch auf das 
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klassische »Kleingedruckte«. Überlegen Sie sich eventuelle Konse- 
quenzen bestimmter Klauseln. Im folgenden einige Hinweise zu even- 
tuellen Hürden in Vertrágen. 

- Eine Klausel, die bestimmt, daß Sie sämtliche Unterlagen und Daten 
über Ihr Programm Ihrem Partner »bedingungslos« überlassen, sollte 
der Vertrag auf keinen Fall enthalten. Mit diesem Schritt verkaufen Sie 
Sich nämlich vollends an das Softwarehaus. 

- Sollte im Vertrag die Rede von Vorkaufsrecht sein, bedenken Sie, 
daB Sie dann eventuelle weitere Produkte aus Ihrer Software- 
Schmiede zuerst immer Ihrem Vertragspartner anbieten müssen. Sol- 
che Klauseln sollten Sie, ohne entsprechende vertragliche finanzielle 
Absicherung dieses Vorverkaufsrechtes zu Ihren Gunsten, nicht ak- 
zeptieren. 

- Viele Programmierer arbeiten mit einer eigenen Modulbibliothek, 
das heißt sie verwenden gleiche Programmteile in verschiedenen Pro- 
grammen. Wenn Ihr Partner von Ihnen verlangt, daß Sie alle im betref- 
fenden Produkt verwendeten Programmteile in anderen Publikationen 
nicht mehr verwenden dürfen, sollten Sie von einem Vertrag Abstand 
halten. 

- Es ist grundsátzlich zu empfehlen - vor allem bei Summen unter 
30000 DM - für einen festen Honorarsatz zu arbeiten. Sie gehen dann 
kein unnótiges Risiko ein. Denn erstens ist es sehr schwer, den Um- 
satz, den Ihr Produkt erzielt, zu kontrollieren. Zudem kann es passie- 
ren, daß Ihr Partner versucht, Ihnen Unkosten - etwa für Werbung - 
anzulasten. 

- Haben Sie Ihr Programm fertiggestellt, lassen Sie es von Ihrem Ver- 
tragspartner gründlich testen. Lassen Sie sich schriftlich bestátigen, 
daß das Programm einwandfrei läuft. Nur so können Sie vermeiden, 
daß eventuell später auftauchende Fehler Ihnen angelastet werden 
und Sie die Konsequenzen daraus zu tragen haben. 
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Amiga Fun & 
Games 


Wie der Titel dieses Buches 
verrät, wird ein spezielles Ge- 
biet der Amiga-Basic-Program- 
mierung behandelt, die Spiele- 
programmierung. Dieses Werk 
setzt Grundkenntnisse in der 
Basic-Programmierung voraus. 
Es ist daher nicht für den abso- 
luten Einsteiger gedacht. Um 
den Umfang in einem akzepta- 
blen Rahmen zu halten, wurde 
darauf verzichtet die Befehle 
genauer zu erklären und dafür 
das eigentliche Thema intensiv 
behandelt. Wie auch im »Amiga 
BASIC-Know-How«-Buch die- 
ses Verlages werden insbeson- 
dere Lösungswege für be- 
stimmte Probleme aufgezeigt. 
Das Hauptaugenmerk lag dar- 
auf, Lösungswege für die Spie- 
leprogrammierung zu entwik- 
keln, die universell einsetzbar 
sind. 

Das gesamte Buch unterteilt 
Sich in drei Hauptthemengebie- 
te, die Strategie- und Taktikspie- 
le, die Adventures und die Ac- 
tionspiele. Anhand eines Pro- 
jektes für jede dieser Spielegat- 


tungen wird Schritt für Schritt 
eine brauchbare Lósung ent- 
wickelt. Wobei alle Spiele auf 
Diskette beiliegen. 

In einem . 3D-Tic-Tac-Toe- 
Spiel wird gezeigt, mit welchen 
Algorithmen dem Computer 
Strategie und Taktik beige- 
bracht werden. Die Erklärun- 
gen dieser Algorithmen sind 
stets verständlich, nachvoll- 
ziehbar und lassen sich auf die- 
se Weise auch leicht durch ei- 
gene ergänzen. 

An einem Wallbreaker-Spiel 
wird der Aufbau und Nutzen ei- 
nes Game-Construction-Sets 
erklärt. Da für jedes Themen- 
gebiet ein recht umfangreiches 
Programm aufgebaut wird, läßt 
sich die technische Umsetzung 
der Programmidee gut nach- 
vollziehen. In einigen Unterka- 
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piteln überwiegt jedoch das Li- 
Sting gegenüber der Beschrei- 
bung. Um die Programme lei- 
stungsfáhig zu machen, wur- 
den die Betriebssystemrouti- 
nen einbezogen und ausführ- 
lich deren Verwendung erklärt. 

Im Kapitel über die Grafik- 

Adventure-Programmierung 
wird von der optimalen Planung 
über das Schreiben eines Dreh- 
buchs bis zur Programmumset- 
zung alles erklárt. So erfahren 
Sie, wie man einen leistungsfá- 
higen Parser programmiert. 
Wie mit Raummodulen ein viel- 
Seitiges Spiel entsteht oder wie 
IFF-Grafiken in Adventure inte- 
griert werden. Weitere Anre- 
gungen fordern den Leser dazu 
auf, eigene Erweiterungen zu 
programmieren. 

Im Kapitel über Actionspiele 
erfahren Sie viel über Libraries 
und Structures, da nur auf die- 
se Weise Geschwindigkeit er- 
reicht wird. Dies ist auch das 
Kapitel, in dem alles über Spri- 
tes und deren Animation sowie 
die schnellé Grafikausgabe zu 
finden ist. Wie auch in den vor- 
herigen Kapiteln wird ein Spiel 
in den einzelnen Schritten ge- 
plant (Spielprinzip, Planung der 
Grafik, Hauptprogramm, ver- 
Schiedene Level etc.). 

Im sechsten Kapitel werden 
noch weitere Ausblicke auf die 
Möglichkeiten in Amiga-Basic 
undanderen hóheren Program- 
miersprachen gegeben. 

Das Buch ist gut gegliedert 
und stellt die wichtigsten Spie- 
legattungen und deren Lósung 
vor. Jedes Kapitel beginnt mit 
der Planung und Ausarbeitung 
der Spielidee. Daraufhin wer- 
den in einzelnen Phasen eine 
Reihe von Unterprogrammen 
erstellt und zuletzt das koordi- 
nierende Hauptprogramm pro- 
grammiert. Diese Programmer- 
stellung dient dem übersichtli- 
chen und professionellen Pro- 
grammieren. Es wurde beson- 
derer Wert darauf gelegt, dem 
Leser ein móglichst abstraktes 
und auf einzelne Prozeduren 
verteiltes Programmieren па- 
hezulegen. Dies ist nicht nur für 
die Spieleprogrammierung, son- 
dern für jedes andere Projekt 
sinnvoll. Der in Basic ungelieb- 
te »Spaghetticode« wird, wenn 
móglich, vermieden. 

»Amiga Fun & Games« ist für 
denjenigen zu empfehlen, der 
Sich intensiver mit der Program- 
mierung von Spielen jeglicher 
Art bescháftigen will. Man sollte 
aber schon Erfahrung mit 
Amiga-Basic haben, da das 
Wissen über die einzelnen 
Kommandos und deren Funk- 
tionsweise vorausgesetzt wird. 


Aus unserem 


Es wird Wert darauf gelegt, die 
speziellen Probleme der Spie- 
leprogrammierung global zu er- 
kláren und danach in einen Pro- 
grammcode umzusetzen. Da- 
her sind einige Kapitel nicht nur 
auf Amiga-Basic beschránkt. 
Der Parser z.B. kann leicht auch 
in andere Programmierspra- 
chen umgesetzt werden. 

Die auf Diskette beiliegenden 
Programme beweisen, daß 
auch in Basic gute Spiele ge- 
schrieben werden können. Es 
kommt nur darauf an, wie man 
die Fähigkeiten des Amiga- 
Basic nutzt. Andreas Regul/pe 


‚Amiga Fun & Games; Körting; AV Alpha Verlag 
AG; 336 Seiten; Preis 59,90 Mark. 


Amiga-BASIC- 
Know-How 


Das Amiga-Basic-Buch von 
Bonau/Körting ist ein weiterfüh- 
rendes Buch in der Basic-Pro- 
grammierung auf dem Amiga. 
Es wendet sich daher auch 
nicht an den Einsteiger, son- 
dern ist für denjenigen gedacht, 
der sich schon mit dieser Pro- 
grammiersprache beschäftigt 
hat und den Befehlssatz und 
deren Funktion kennt. Das 
Werk zeigt auf, was sich mit 
Amiga-Basic erreichen läßt und 
wo die Grenzen des Interpre- 
ters liegen. 

Im ersten Kapitel befassen 
Sich die Autoren mit der richti- 
gen Planung und Ausarbeitung 
einer Programmidee. Außer- 
dem wird groBer Wert auf guten 
Programmierstil gelegt. Das 
zweite Kapitel enthált alles Wis- 
senswerte über Grafik und Ani- 
mation. Hier werden Balken- 
und Tortengrafiken, Animation 
durch Farbrotation, Scrolling, 
ráumliche Darstellungen, Frak- 
tale, Sprites und verschiedene 
Zeichensätze erklärt. Beispiel- 
programme, die auch auf der 
beiliegenden Diskette zu finden 
sind, verdeutlichen die Funktio- 
nen und stellen sinnvolle Hilfs- 
programme dar. 

Im dritten Kapitel geht es 
dann an die Hardware. Sie ler- 
nen, wie Peripheriegeräte di- 
rekt über Hardwareadressie- 
rung gesteuert werden und wie 
Sie von Amiga-Basic aus einen 
neuen Task starten. Hierbei 
wird intensiver Gebrauch von 
den  Betriebssystemroutinen 
gemacht. 

Das vierte Kapitel bescháftigt 
Sich mit den Hilfsprogrammen 


Ein Programmierer 
wie ein Fisch ohne 
nicht auf dem 
schwimmen, haben 
für Sie 

ausgewáhlt. 


(Tools und Utilities). Für die pro- 
fessionelle Programmierung 
erfahren Sie, welche Vorteile 
Universal-Tools bieten. Weiter- 
hin werden in diesem Kapitel 
drei gróBere Tools entwickelt 
und beschrieben. Im folgenden 
Kapitel sind einige Besonder- 
heiten der Programmierung 
enthalten. Neben dem Aufbau 
eines Password-Schutzes wer- 
den Sortierverfahren erläutert 
und ein Beispiel zur recht unbe- 
kannten Autoprogrammierung 
(Programmtext entwickelt sich 
selbst) gegeben. 

Im sechsten Kapitel befinden 
Sich Tips und Tricks, die häufig 
auftretende Fehler oder Proble- 
me mit dem Editor des Amiga- 
Basic erkláren. AuBerdem fin- 
den Sie hier Anregungen und 
Hinweise ähnlich den »Tips und 
Tricks« im AMIGA-Magazin. 

Insgesamt wurde in diesem 
Buch sehr viel Wissen auf etwa 
300 Seiten komprimiert. Die Au- 
toren gehen davon aus, daß die 
Funktionsweise von Basic- 
Befehlen dem Leser keine 
Schwierigkeiten bereitet. Des- 
halb wurde darauf verzichtet, 
die reine programmtechnische 
Lösung zu erläutern. Vielmehr 
steht die Lösung eines überge- 
ordneten Problems, wie die 3D- 
Projektion auf dem Bildschirm, 
die realistische Darstellung mit 
Hilfe schattierter Drahtgittermo- 
delle oder die Fraktaldarstel- 
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Bücher-Regal 


ohne Bücher ist 
Wasser. Damit Sie 
Trocknen 

wir einige Bücher 


lung; im Vordergrund. Im Kapi- 
tel zur 3D-Projektion ist ein gu- 
tes mathematisches Verständ- 
nis von Vorteil. Da das Buch auf 
relativ wenigen Seiten sehr viel 


Wissen vermittelt, ist die 
Schreibweise zum Teil etwas 
trocken. Im Vergleich zum Ami- 
ga-Basic-Buch von Data 
Becker fehlen auflockernde 
Einschübe. Das Buch richtet 
sich jedoch an einen anderen 
Leserkreis. Es ist für denjeni- 
gen empfehlenswert, der sich 
mit Amiga-Basic bereits aus- 
giebig beschäftigt hat und mit 
Hilfe dieses Werkes professio- 
nell arbeiten will. Hierzu bietet 
es viele Anregungen und zeigt 
in Beispielen, wie die beschrie- 
benen Verbesserungen ver- 
wirklicht werden kónnen. Wer 
diese Funktionen in seine Pro- 
gramme einbaut, kann eine Be- 
nutzerfreundlichkeit erreichen, 
die Programmen in anderen hó- 
heren Programmiersprachen in 
nichts nachsteht. 

Andreas Regul/pe 
Amiga-BASIC-Know-How; Bonau/Kórting; AV- 


Alpha Computer Verlag AG; 304 Seiten; Preis 
5990 Mark. 


Amiga-Basic 


Das »Amiga-Basic«-Buch von 
Hannes Rügheimer und Chri- 
stian Spanik stellt ein umfang- 
reiches Standardwerk für jeden 
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Amiga-Basic-Programmierer 
dar. Es ist sowohl für den Ein- 
steiger als auch für Fortge- 
Schrittene geschrieben. Um 
beiden Ansprüchen gerecht zu 
werden, schrieben die Autoren 
zwei Einleitungen, eine, welche 
dem Anfánger die Grundbegrif- 
fe vermittelt, und eine zweite, 
die dem Fortgeschrittenen den 
schnellen Einstieg ermóglicht. 

Jeder einzelne Themenbe- 
reich wird ausführlich und 
nachvollziehbar dargestellt: 
Dabei verfallen die Autoren 
nicht in eine trockene und an- 
onyme Schreibweise, sondern 
Sie lockern den Text durch klei- 
ne Kommentare auf. 

Dies ist auch das herausra- 
gendste Merkmal des Buches. 
Im Gegensatz zu anderen Wer- 
ken versuchen die Autoren mit 
Hilfe von kleinen Karikaturen, 
witzigen Einschüben oder eige- 
nen Kommentaren den manch- 
mal doch recht trockenen Stoff 
auf amüsante Weise zu vermit- 
teln. Hin und wieder schildern 
sie auch die kleineren und gró- 
Beren Probleme, die sie wäh- 
rend des Schreibens hatten. All 
dies und auch der recht witzige 
Dialog der beiden Autoren ganz 
zu Anfang nimmt dem Buch 
das Lehrwerkhafte. 

Das ganze Werk ist Schritt für 
Schritt gegliedert, d.h. zunáchst 
werden die Grundlagen ge- 
schaffen und danach in aufstei- 


Bücher 


gendem Schwierigkeitsgrad die 
weiteren Themen besprochen. 
Deshalb ist es am sinnvollsten, 
das Buch Seite für Seite durch- 
zuarbeiten, da in den späteren 
Kapiteln auf das aufgebaute 
Wissen zurückgegriffen wird. 

Im ersten Kapitel wird die Ani- 
mation von Bobs und Sprites 
sehr ausführlich erläutert. Da- 
nach werden die Grafikfähigkei- 
ten des Amiga (Auflösungsstu- 
fen, Screen- und Windowdefini- 
tion) erklárt, wobei anschauli- 
che Beispielprogramme das 
Verstehen erleichtern. Das drit- 
te Kapitel befaBt sich mit der 
Verwaltung von Daten auf Dis- 
ketten und kleinen Tools zu die- 
sem Thema. Im Kapitel über 
Bilderverarbeitung erfahren Sie 
nebenbei auch alles über die 
IFF-Austauschformate des Ami- 
ga. Auch die herausragenden 
Soundfähigkeiten werden ge- 
bührend behandelt. 

Das vierte Hauptkapitel geht 
noch etwas über das Amiga- 
Basic hinaus. Hier werden die 
Unterschiede von Interpretern, 
Compilern und der Maschinen- 
sprache erklärt. Außerdem er- 
halten Sie eine äußerst ausführ- 
liche Anleitung des Basic-Com- 
pilers von AC/Basic. 

Jedes Kapitel des Buches 
enthált gut dokumentierte Bei- 
spielprogramme, welche, um 
Ihnen das Abtippen zu erspa- 
ren, auf Diskette beiliegen. Zum 
Teil werden auch gróBere Pro- 
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jekte Schritt für Schritt ent- 
wickelt und so die Arbeitsweise 
eines Programmierers gezeigt. 
Im Ausarbeiten des Anhangs 
haben sich die beiden Autoren 
groBe Mühe gegeben. In den 
einzelnen Kapiteln werden die 
Amiga-Basic-Fehlermeldun- 
gen erklárt und Vorschláge für 
deren Lósung gegeben, alle 
Befehle des Interpreters wer- 
den mit Parameterangabe und 
Funktionsweise beschrieben, 
die Beispielprogramme auf der 
Commodore-Extras-Diskette 


werden erläutert und schließ- 
lich sorgt ein Fachwortlexikon 
für den nötigen Durchblick bei 
Fremdwörtern aus dem Com- 
puterbereich. 

Trotz des sehr ausführlichen 
und verständlich geschriebe- 
nen Textes, soll jedoch auf zwei 
Kritikpunkte hingewiesen wer- 
den. In der momentan aktuell- 
sten 5. Auflage des Buches wird 
nur der AC/Basic-Compiler be- 
schrieben. Es wäre wün- 
schenswert, wenn die Autoren 
für die nächste Auflage eine 
kleine Ergänzung vornähmen 
und auch den recht neuen 
Hisoft-Basic-Compiler berück- 
sichtigten. Ein kleiner Ver- 
gleichstest der beiden Compi- 
ler ware für den Leser eine wün- 
schenswerte Kaufhilfe. 

Wichtiger ist jedoch der zwei- 
te Kritikpunkt: Da sich das 
Buch laut Autoren auch an die 
fortgeschritteneren Basic-Pro- 
grammierer wendet, sollte auch 
eine professionellere Program- 
mierweise berücksichtigt wer- 
den. Hierzu gehört speziell die 
Verwendung von Betriebssy- 
stemroutinen. 

In dem sehr umfangreichen 
Werk wird mit keinem Wort der 
Aufruf von Funktionen und Be- 
fehlen aus den LIBRARY- 
Dateien beschrieben. Um je- 
doch professionelle Program- 
me auch mit Amiga-Basic pro- 
grammieren zu können, sind 
diese Bibliotheken unerläßlich. 
Mit ihrer Hilfe wird es zum Teil 
erst möglich, bestimmte Pro- 
grammfunktionen zu verwirkli- 
chen. 

Dieses Buch ist besonders 
für den Einsteiger geeignet, 
der auf diesem Wege erste Er- 
fahrungen im Programmieren 
sammeln will. Die verständliche 
und teilweise auch amüsante 
Schreibweise sorgt dafür, daß 
auch nach den ersten 200 Sei- 
ten der Spaß am Lesen nicht 
verlorengeht. Aber auch für den 
etwas fortgeschritteneren Basic- 
Programmierer finden sich hier 
nützliche Tips und eine Menge 
Hintergrundwissen. »AmigaBa- 
sic« von Data-Becker ist daher 
sowohl für den Anfänger als 
auch für den Fortgeschrittenen 
empfehlenswert. 

Andreas Regul/pe 


Amiga Basic; Rügheimer/Spanik; Data 
Becker Verlag; 792 Seiten; Preis 59,00 Mark. 


Sollten Sie Interesse an 
Literatur in den Program- 
miersprachen C und As- 


sembler haben, bitten wir 
Sie, in unserem Bücherre- 
gal der Ausgabe 4 »C und 
Assembler« zu stóbern. 
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Fortsetzung von Seite 27. 


struct MathBase *MathBase; 

struct MathTransBase *MathTransBase; 

struct Screen *VGscreen; 
struct RastPort *VGrastport; 
struct ViewPort *VGviewport; 
struct VGLine *VGLinesMem; 
struct VGPoint *VGPointsMem; 
char VGErrFile(80]=""; 

ULONG VGLinesMemSize,VGPointsMemSize, 
VGNumLines=0, VGNumPoints=0, 
VGMaxLines,VGMaxPoints, 
VGxorigin, VGyorigin; 

union VGzahl VGscalex,VGscaley; 


/* Ausgabe von Fehlermeldungen nach stderr und Errorfile */ 


BOOL VGerror(Funcname,errname) 
char Kerrname, *Funename; 
{ FILE ер; 

time_t tm; 

char timestr[80]; 

int length; 


tm=time(NULL) ; 
length=strlen(ctime(&tm))-5; 
strnepy(timestr,ctime(&tm) ‚length) ; 
timestr[length]=0; 


fprintf(stderr, "Ze $12s: Ze ERROR.\n”,timestr,Funcname,errname) ; 


if (strlen(VGErrFile)!-0) 
[ 
if (!(fp=fopen(VGErrFile, "a"))) 
[ 
fp=fopen(VGErrFile, ^w"); 


if (Пер) ( return (FALSE); ) 


fprintf(fp,"Zs $125: %s ERROR. Wn",timestr,Funcname,errname); 


fclose(fp); 


return (TRUE); 
) 


/% Setzen der Farbpalette %/ 
BOOL VGeolor(Pos,Anzahl,Colors) 
unsigned int Pos,Anzahl; 
struct VGColor XColors; 


І 


int 1; 


if (!VGsereen) 
( 


VGerror("VOcolor",ERR FIRSTOPEN) ; 
return FALSE; 


if ((Ров+Апгаћ1) > 32) 
[ 
VGerror("VGcolor^,ERR FALSEPAR) ; 
return FALSE; 
) 
for (41=0;1<Anzahl; i++) 
[ 
if ((Colors[1].R > 15) 11 (Colors(1].G > 15) 11 
(Colors[i].B > 15)) 
( 


VGerror( “VGcolor”,ERR_FALSERGB) ; 


SetROBA(VGviewport,Pos*i,Colors[i].R&15,Colors[1].0&15, 
Colors[i].B&15); 
) 

return TRUE; 


) 


/* Alle Libraries schließen und Speicher wieder freigeben */ 


void VGelose(end) 
BOOL end; 
( 


АҒ (mask % SCREEN) ( CloseScreen(VGscreen) ; } 


if (mask & LINEMEM) | FreeMem(VGLinesMem, VGLinesMemSize); ) 
if (mask & POINTMEM) | FreeMem(VGPointsMem,VGPointsMemSize) ; } 


if (mask & MATHTRANS) | CloseLibrary(MathTransBase) ; } - 


if (mask & MATHFFP) | CloseLibrary(MatnBase); } 
if (mask & GRAPHICS) | CloseLibrary((struct Library *)GfxBase); 


if (mask & INTUITION) { CloseLibrary((struct Library *) 
IntuitionBase) ; } 

mask=0; 

if (lend) exit(10); 

] 


/* Libraries und Screen öffnen, Speicher reservieren, Initialisierun- 


LEA 


void VGopen(AuflsgX,AuflsgY,BitPlanes,MaxLines,MaxPoints,ErrFile) 


int AuflsgX,AuflsgY,BitPlanes; 
unsigned int MaxLines,MaxPoints; 
char *ErrFile; 
{ 
if (mask) 
{ 
VGerror(^VGopen", ERR ALREADYOP) ; 
VGolose(FALSE) ; 


Strnepy(VGErrFile,ErrFile,79); 
VGErrFile[79)=0; 
VGLinesMemSize=MaxLines * sizeof(struct VGLine); 
VGPointsMemSize=MaxPoints * sizeof(struct. VGPoint) ; 
VGMaxLines=MaxLines; 
VGMaxPoints=MaxPoints; ч 
switch (AuflsgX) 
( 
case 640: VGnewscreen.Width=640; 
VGnewscreen.ViewModes=HIRES; 
break; 
case 320: break; 
default : VGerror("VGopen",ERR DISPX); 
} 
switch (AuflsgY) 
( 
case 256: VOnewscreen.Height=256; 
break; 
case 400: VGnewscreen.Height=400; 
VGnewscreen.ViewModesl =LACE; 
break; 
case 512: VGnewscreen.Height=512; 
VGnewscreen.ViewModesl =LACE; 
break; 
case 200: break; 
default : VGerror("VGopen",ERR DISPY); 


if ((BitPlanes>0) && (BitPlanes<=5)){VGnewscreen.Depth=BitPlanes; } 
else ( VGerror("VGopen",ERR DISPB); | 


IntuitionBase=(struct IntuitionBase *)OpenLibrary 
("лёлі Лоп. library”, 0); 
Ағ (!IntuitionBase) 


VGerror( "VGopen", ERR. OPINTUITION) ; 
VGelose(FALSE) ; 


mask |= INTUITION; 


GfxBase=(struct GfxBase *)OpenLibrary(”graphics.library”,0); 


if (!GfxBase) 


VGerror( “VGopen”, ERR. OPGFX) ; 
VGelose(FALSE) ; 


mask |= GRAPHICS; 


MathBase=(struct MathBase *)OpenLibrary("mathffp.library^,0); 


if (IMatnBase) 


VGerror( "VGopen", ERR. OPMATHFFP) ; 
VGelose(FALSE) ; 


mask |= MATHFFP; 

MathTransBase=(struct MathTransBase *)OpenLibrary 
("mathtrans.library”,0); 

if (!MathTransBase) 


VGerror( “VGopen” ,ERR_OPMATHTRANS) ; 
VGelose( FALSE) ; 


mask |= MATHTRANS; 
if (VGLinesMemSize) 
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{ VGscaley.1)); 
VGLinesMem=(struct VGLine *) if(startx> =VGnewscreen.Width){ startx=VGnewscreen.Width-1; ) 
AllocMem (VGLinesMemSize,MEMF_PUBLIC | MEMF_CLEAR) ; if(endx >=VGnewscreen.Width)[endx =VGnewscreen.Width-1; | 
f (!VGLinesMem) if(starty>=VGnewscreen.Height){ starty=VGnewscreen.Height-1; ] 
{ if(endy >=VGnewscreen.Heignt)[endy =VGnewscreen.Height-1; | 
VGerror( "VGopen”,ERR_OUTMEN) ; if (startx < 0) startx=0; | 
VGelose(FALSE) ; if (enàx < 0) i] 
1 if (starty < 0) A 
mask |= LINEMEM; if (endy < 0) 20; ] 
Move(VGrastport,startx,starty); 
1f (VOPointsMemSize) 1 Draw(VGrastport,endx,endy); 
( ) 
VGPointsMem=(struct VGPoint X) } 
AllocMem (VGPointsMemSize,MEMF_PUBLIC | MEMF. CLEAR); 
f (1VGPointsMem) /* Linie definieren und übernehmen */ 
( void VOline(Num,Anfang,Ende,Color) 
VGerror( "VGopen", ERR. OUTMEM) ; int Num; 
VGclose(FALSE) ; Short Color; 
1 int Anfang,Ende; 
mask 1 = POINTMEM; 


} if ((Anfang>=VGNumPoints) || (Ende>=VGNumPoints)) 
if (1 (VGLinesMemSize+VGPointsMemSize) ) ( 


( VGerror (“VGline”,ERR_UNDEFPOINT) ; 
VGerror( “VGopen”, ERR_NOTHING) ; } 
1 else 
VGscreen=(struct Screen %) OpenScreen(&VGnewscreen) ; 
if (!VGscreen) if (VGNumLines >= VOMaxLines) 
( ( 
= Үбегтог(”Үбореп”,ЕВЕ OESCH) VGerror ("VGline",ERR TOOMLINES); 
VGelose(FALSE) ; ) 
) 
mask |= SCREEN; a 
ү = - ; 
Wee 3 pean d VOLinesMen[VGNunLAnes) .Nunber Nun; 
SCC i VGLinesMem[VGNumLines] .StartPoint = Anfang; 
gege Eer овы 
VGxorigin = VOnewscreen.Width/2; nesMen[ Л 


VGyorigin = VGnewsereen.Height/2; ) 
if ((VGxorigin/2) > VGyorigin) } 
{ 
VGscalex.f=(float)VGnewscreen.Height; 
ж Punkt definieren und übernehmen %, 
V6scaley.f=(float)VGyorigin; MUR VGpoint (0b Koord) / 
, 
int 05); 
union VGzahl *Koord; 
( { if (VGNumPoints >= VGMaxPoints) 
А ( 
se SERES > Voyorigin) VGerror ("VGpoint”,ERR_TOOMPOINTS) ; 
VGscalex.f=(float)VGyorigin; ud 
VGscaley. f=(float)VGyorigin; { 
) 


else VGPointsMem[VGNumPoints] .Object=0bj ; 


( VOPointsMem[VGNumPoints].Koord[0]sKoord[0]; 


е £=(float) (Veyorigin/2); VGPointsMen[VGNumPoints].Koord[1]-Koord[1]; 
MIO А сеч Сая gc D V6PointsMem[VGNumPoints] .Koord[2]=Koord[2]; 
‘pa NEE VGPointsMem[VGNumPoints++] .Koord(3] . f=FPONE; 


] 
) А } 


/* Darstellungsroutine */ /* Zuvor definiertes Objekt löschen */ 
void See void VGeraseob) (PointObj) 
BOOL clear; int PointObj; 
| { 
t 


ister int 1=0,),а,0; 
register int i,startx,starty,endx,endy; wahai Rb 


f (PointObj!-0 
if (clear) | SetRast(VGrastport,0); } трал) 


SetDrMd(VGrastport, JAM1) ; 


v ints, 
for (1-0; 1 < VGNumLines; i++) while (1<VGNumPoints) 


{ 


f (PointObj--VOPointsMem[i].Object) 
SetAPen(VGrastport,VGLinesMem[i].Color); Й 
startx = VGxorigin+SPFix(SPMul( for (J=i+1;j <VGNumPoints; J++) 
VGPointsMem[VGLinesMen[1].StartPoint].Koord[0].1, 
VGscalex.i)); 
starty = VGyorigin+SPFix(SPMul( 
VGPointsMem[VGLinesMem[i].StartPoint].Koord[1].i, 
VGscaley.i)); 
VGxoriginsSPFix(SPMul( 
VGPointsMem[VGLinesMen[i].EndPoint].Koord[0].i, 
VGscalex.i)); 
Voyorigin+SPFix(SPMul( 
VGPointsMem[VGLinesMem[i].EndPoint].Koord[1].1, Listing 1. (Fortsetzung) 


VOPointsMem[j-1) .Object-VOPointsMem(J].0bject; 


AMIGA-SONDERHEFT 7 141 


VGPointsMen(j-1] .Коога[0)=УСРоїпёзМеп[ 3) .Koord(0] 
VGPointsMen[j-1].Koord[1]-VGPointsMen[j] .Koord[1]; 
VGPointsMen[]-1).Koord[2]-VGPointsMen[j] .Koord(2] ; 
VGPointsMen[j-1].Koord[3]-VGPointsMen[j] .Koord(3] ; 


) 


VGNumPoints--; 


for (a=0;a<VGNumLines;a++) 
{ 
if ((VGLinesMem(a].StartPoint==i)I1 (VGLinesMem 
[a] .EndPoint==1)) 
( 


for (b=a+1;b<VGNumLines;b++) 
( 
VGLinesMem[b-1).NumbersVGLinesMem 
[b].Number; 
VGLinesMem[b-1] .StartPoint=VGLinesMem 
[b].StartPoint; 
VGLinesMem[b-1] .EndPoint=VGLinesMem 
[b].EndPoint; 
VGLinesMem[b-1].Color=VGLinesMem 
[b).Color; 
) 
VGNumLines--; 
} 
if (VGLinesMem[a].StartPoint>i) 
( 
VGLinesMem[a].StartPoint-= 1; 
) 
if (VGLinesMem(a].EndPoint >i) 
| 
VGLinesMem[a].EndPoint-= 1; 
] 
] 
] 
else | i++; } 
} 
] 
else 
[ 
VGNumPoints=0; 
VGNumLines=0; 


] 


/* Einzelne Linie löschen %/ 
void VGeraseline(LineNum) 
int LineNum; 

( 


register int i,j; 


if (LineNum!=0) 
1 
1=0; 
while (i« VGNunLines) 
[ 
if (LineNum==VGLinesMem[1].Nunber) 
І 
for (j21«1;] « VoNunLines; j++) 
[ 
VGLinesMem[j-1] .Number=VGLinesMem[j].Number; 
VGLinesMem[j-1] .StartPoint=VGLinesMem 
[J] -StartPoint; 
VGLinesMem(j-1] .EndPoint=VGLinesMen[j].EndPoint; 
VoLinesMem[j-1].ColorsVGLinesMem[]].Color; . 
} 
VGNumLines--; 


] 


else | із; ] 
] 
} 
else | VONunLines-0; | 


] 


/* Datenfile einlesen */ 
BOOL VGreaddata(FileName) 
char *FileName; 

( 

int ` i,PointNum,LineNum; 
struct VGPoint Point; 


142 


Struct VGLine Line; 
FILE тр; 


if (!(fp=fopen(FileName, т”))) 


VGerror ("VGreaddata”,ERR_CANTOPENFILE) ; 
return (FALSE) ; 


fscanf(fp, "£d", &PointNum); 
fscanf(fp, "£d", &kLineNum) ; 
if ((PointNum > VGMaxPoints) || (LineNum > VCMaxLines)) 


VGerror ("VGreaddata",ERR. LOWRESMEM) ; 
felose(fp); 
return (FALSE); 


for (1=0;1<PointNum; i++) 

fscanf(fp; "*d%e%e%e”, &(Point. Object) ,&(Point.Koord (01), 
&(Point.Koord[1]),&(Point.Koord[2])); 
VGpoint(Point.0bject,Point.Koord); 

for (120;1« LineNun; i++) 

fscanf(fp, "%d%d%h”,&(Line.StartPoint),‚&(Line.EndPoint), 


&(Line.Color)); 
VGline(1+1,Line.StartPoint, Line.EndPoint,Line.Color) ; 


fclose(fp); 
return (TRUE); 


/* Matrix auf Objekt(e) anwenden */ 
void VGtransform(Obj,Matrix) 
union VGzahl Matrix[][VODIM]; 
int 05); 
( 
register int a; 
union VGzahl MH[VGDIM]; 


for (a-0;a« VGNumPoints;a++) 
( 
1f ((10bj)I1 (VGPointsMem[a].Object==06j)) 
( 


MH(0).f=FPZERO; 
MH[0] .4=SPAdd(MH(0] .4,SPMul(Matrix(0] [0]. 1, VOPointsMem" 
[a].Koord[0].1)); 
MH(0] . 1-SPAdd (MH[O] . i, SPMu1 (Matrx[0)[1]. 1, VaPo1ntsMem 
[а] .Коога[1].1)); 
MIO). 1-SPAdd (MH[0] . 1, SPMu1 (Matrix[0] [2]. 1, VOPo1ntsMem 
[a].Koord[2].1)); 
«МН(01.4-5РАйа(МН(01.1,5РМи1(Ма%гіх(01131.1,У0Ро1п%өМеп 
[a].Koord(3].1)); 
MH[1] . f=FPZERO; 
MH[1] .1-SPAdd (MH[1]. 1, SPMu1 (Matrix[1][0].1, VOPointsMem 
(81.Коог4(01.4)); 
MH(1]. 1-SPAdd(MH[1]. 1, SPMul(Matrix[1)[1].1, VGPointsMem 
[a].Koord(1).1)); 
MH[1] . 1-SPAdd (MH[1]. 1, SPMul(Matrix[1][2].1,VGPointsMem 
[8].Koord[2].1)); 
MH[1] . 4=SPAdd(MH(1].1,SPMul (Matrix(1][3].1, VaPointsMem 
[a].Koord[3].1)); 
MH[2] . f-FPZERO; 
MH[2] . 1-SPAdd (MH[2] . 1, SPMul(Matrix[2][0].1,VGPointsMem 
(а1.Коога(01.1)); 
MHL2].i=SPAdd(MH[2].i,SPMul(Matrix[2][1].1,VGPointsMem 
[а] .Коога[1].1)); 
MHL2].1=SPAdd(MH[2].1,SPMul(Matrix[2][2].1,VGPointsMem 
[а].Коога[2].1)); 
MH[2] .1=SPAdd(MH[2].1,SPMul(Matrix[2][3].1,VGPointsMem 
[a].Koord[3].1)); 
MHL3].£=FPZERO; 
MH(3] .i=SPAdd(MH[3].1,SPMul(Matrix[3][0]:1,VGPointsMem 
[8].Koord[0].1)); 
7SPAdd(MH[3]. 1, SPMul(Matrix[3][1].1,VGPointsMem 
[a].Koord[1].1)); 
MH[3] .1-SPAdd (MH[3] . 1, SPMul (Matrix[3]([2].1,VGPointsMem 
[а] .Коога[2].1)); 
MH(3] . 1-SPAdd(MH[3] . 1, SPMu1 (Matrix[3] [3]. 1, VGPointsMem 
[a].Koord[3].1)); 


M83] 
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P ROJEKT 


VGPointsMem[a] .Koord[0] =МН(0]; 
VGPointsMen[a] .Koord[1]-MH[1]; 
VGPointsMem[a].Koord[2]-MH[2]; 
VGPointsMem[a].Koord[3]-MH[3]; 
] 


void VGglobalscale(RMatrix,scalefactor,clear) 
union VGzahl RMatrix[][VODIM]; 

float scalefactor; 

BOOL clear; 

| 


union VGzahl SMatrix[VODIM][VODIM]; 


SMatrix[0][0]. f=scalefactor; 


/* Umrechnung von Grad in Bogenmab */ 
float VGdeg_rad(VGdegree) 
int VGdegree; 


union VGzahl VGangle; 
VGangle.i = SPMul(SPDiv(SPF1t(180),VGPI), ((f1oat)VGdegree)); 


return(VGangle.f); 


/* Matrix kopieren */ 
void VGcopylongmatrix(MatrixA, MatrixB) 
union VGzahl *MatrixA,*MatrixB; 


SMatrix[0)[1].f-FPZERO; 
SMatrix[0][2]. 
SMatrix[0](3]. 
SMatrix[1] [0]. f=FPZERO; 
SMatrix[1](1].f-scalefactor; 
SMatrix[1] [2]. f=FPZERO; 
ЅМа+гіх[1) [3]. f=FPZERO; 
SMatrix[2][0].f=FPZERO; 
SMatrix[2][1].f-FPZERO; 
SMatrix[2][2].f=scalefactor; 
SMatrix[2] [3] .f=FPZERO; 
SMatrix[3] [0]. £=FPZERO; 
SMatrix(3] [1]. f=FPZERO; 


SMatrix(3] [2]. f=FPZERO; 

SMatrix(3] (3). £=FPONE; 

if (clear) | VGcopylongmatrix(SMatrix,RMatrix); | 

else { VGmullongmatrix(SMatrix,RMatrix,RMatrix); } 


register int 1; 


for (1=0;1< (VGDIMXVGDIM) ;i++) | *(MatrixB+i) = *(MatrixA+i); | 


1 


/% Gerichtete Vergrößerungs- oder Verkleinerungsmatrix erzeugen %/ 
void VGlocalscale(RMatrix,E,scalefactor,clear) 

union VGzahl RMatrix[][VODIM]; 

float E[],scalefactor; 

BOOL clear; 


( 


/* Matrizenmultiplikation #/ 
void VGmullongmatrix(MatrixA,MatrixB,MatrixE) 
union VGzahl MatrixA[][VGDIM],‚MatrixB[][VGDIM],*MatrixE; 


union VGzahl MatrixC[VGDIM] [VGDIM] ; 


register int i,j; union VGzahl SMatrix[VGDIM)[VGDIM]; 


for (i=0;i<VGDIM; i++) 


[ 


for (3-0;) € VODIM; J++) 


SMatrix(0](0].1i-SPAdd(SPMul(SPMul(SPSub(scalefactor,FPONE) ,Е[0]) 
,E(0]) , FPONE) ; 
SMatrix[0](1].1sSPMul(SPMul(SPSub(scalefactor,FPONE) ,Е[1]) ,E[0]) ; 
SMatrix[(0][2].1-SPMul(SPMul(SPSub(scalefactor,FPONE) ,E(2]) ,E(0]) ; 
SMatrix[0][3]. f=FPZERO; 
SMatrix[1]([0].1-SPMul(SPMul(SPSub(scalefactor,FPONE),E(0]) ,E(1]) ; 
SMatrix[1][1).1-SPAdd(SPMul(SPMul(SPSub(scalefaotor,FPONE) ‚E[1]) 
„EL1]) , FPONE) ; 
SMatrix[1] [2]. 1=SPMul(SPMul(SPSub(scalefactor,FPONE) ,E(2]) ,E[1]) ; 
SMatrix[1][3]. £=FPZERO; 
SMatrix[2][0].1=SPMul(SPMul(SPSub(scalefactor,FPONE) ,E[0]) ,E[2]) ; 
SMatrix[2)([1].1-SPMul(SPMul(SPSub(scalefactor,FPONE) ,E[1]) ,E(2]) ; 
SMatrix[2][2]. 1-SPAdd(SPMul(SPMul(SPSub(scalefactor,FPONE),E[2]) 


Matrixc[1](]].i = 

SPAdd(SPMul (MatrixB[1][0).1,MatrixA[0][J] 1) , 

SPAdd(SPMul(Matrixb[1][1).i,MatrixA[1] [3] 1), 

SPAdd(SPMul (MatrixB[1][2) 1, MatrixA[2][4].1) , 
SPMul(MatrixB[i)[3].1,MatrixA[3] [4].1) ))); 

1 


VGcopylorigmatrix(MatrixC MatrixE) ; 


! 


/* Verschiebungsmatrix erzeugen */ 

void VGtranslate(RMatrix,El,E2,E3, length, clear) 
union Vózahl RMatrix[][VODIM); 

float E1,E2,E3, length; 

BOOL clear; 


| 


union VGzahl TMatrix[VGDIM][VGDIM]; 


El *= length; 

E2 *= length; 

E3 *= length; 

TMatrix[0][0]. f=FPONE; 
TMatrix[0][1]. f=FPZERO; 
TMatrix[0][2]. £=FPZERO; 
TMatrix[0][3.f-E1; 
TMatrix(1][0].f-FPZERO; 
TMatrix[1)(1].f-FPONE; 
TMatrix[1)[2].f-FPZERO; 

` TMatrix[1)[3]. ; 
TMatrix[2][0]. 

TMatrix[2][1]. 

TMatrix(2)[2]. 
TMatrix[2][3]-f=E3; 
TMatrix[3][0].£=FPZERO; 
TMatrix[3][1]. f=FPZERO; 
TMatrix[3][2]- 

TMatrix[3][3]. s 
if (clear) | VGeopylongmatrix(TMatrix,RMatrix); | 
else Í VGmullongmatrix(TMatrix,RMatrix,RMatrix); | 


) 


/% Vergrößerungs- oder Verkleinerungsmatrix erzeugen %/ 
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»E[2]) , FPONE) ; 
SMatrix[2][3]- f=FPZERO; 
SMatrix[3][0]. f=FPZERO; 
SMatrix[3](1]. 
SMatrix[3][2]. 
SMatrix[3][3]. £=FPONE; 
if (clear) | VGeopylongmatrix(SMatrix,RMatrix); ) 
else Í VGmullongmatrix(SMatrix,RMatrix,RMatrix); | 


) 


/% Dreidimensionale Drehmatrix erzeugen %/ 
void VGrotate(RMatrix,Xangle,Yangle,Zangle,clear) 
union VGzahl RMatrix[][VODIM); 
int Xangle,Yangle,Zangle; 
BOOL clear; 
{ 
union VGzahl VGRx,VGRy,VGR2,XMatrix[VGDIM][VGDIM], 
YMatrix[VGDIM] [VGDIM] , ZMatrix(VGDIM)[VGDIM] ; 


if (Xangle) 
( 
if (Xangle >= 0) | VGRx.f=VGdeg_rad(Xangle); | 
else ( VGRx.f=VGdeg_rad(360+Xangle) ; ] 
XMatrix[0][0].£=FPONE; 
XMatrix[0][1]-£=FPZERO; 
XMatrix[0][2]-£=FPZERO; 
XMatrix[0][3].f=FPZERO; 
XMatrix[1] [0]. f=FPZERO; 
XMatrix[1] [1] .1=SPCos(VGRx.1) 
XMatrix[1)[2].i-SPSin(SPNeg(VGRx.1)) ; 


Listing 1. (Fortsetzung) 


XMatrix[2][1]. 
XMatrix[2][2]. 
XMatrix(2] (3].f=FPZERO; 
XMatrix[3][0]. 
XMatrix[3][1]. 
XMatrix[3][2].f-FPZERO; 
XMatrix[3][3].f-FPONE; 
) 
if (Yangle) 
( 
if (Yangle >= 0) | VGRy.f=VGdeg_rad(Yangle); } 
else [ VGRy.f=VGdeg_rad(360+Yangle); | 
YMatrix[0][0] . 1-SPCos(VGRy. 1) ; 
YMatrix[0)[1).f-FPZERO; 
YMetrix[0][2).1-SPSin(VORy.1); 
YMatrix[0][3].f=FPZERO; 
YMatrix[1][0].f=FPZERO; 
YMatrix[1][1].f=FPONE; 
YMatrix[1][2].£=FPZERO; 
YMatrix[1][3]. £=FPZERO; 
YMatrix[2)[0].1-SPNeg(SPSin(VORy.1)); 
YMatrix[2][1]. f=FPZERO; 
YMatrix[2][2].i=SPCos(VGRy.4); 
YMatrix[2][3]- £=FPZERO; 
YMatrix(3)[0].f-FPZERO; 
YMatrix[3)[1].f-FPZERO; 
YMatrix[3][2].f-FPZERO; 
YMatrix[3][3].f-FPONE; 
) 
if (Zangle) 
{ 
if (Zangle >= 0) | VGRz.f=VGdeg_rad(Zangle); | 
else [ VGR2.f=VGdeg_rad(360+Zangle) ; 
?Ма%гіх(01(01.1-5РСов(У082.4); 
ZMatrix[0][1].1=SPSin(SPNeg(VORz.1)); 
2Matrix(0] [2]. f=FPZERO; 
ZMatrix[0][3).f-FPZERO; 
ZMatrix[1][0).i-SPSin(VGORz.1); 
ZMatrix[1][1).i1-SPCos(VGRz.1); 
ZMatrix[1](2].f-FPZERO; 
ZMatrix[1)[3]. 
ZMatrix[2)[0]. 
ZMatrix[2][1]. 
ZMatrix[2)[2]. 
ZMatrix[2][3]. 
ZMatrix[3](0]. 
ZMatrix(3)[1]. 
ZMatrix[3)[2. 
ZMatrix[3][3].f=FPONE; 
) 
if (Xangle) 
{ 
if (clear) VGcopylongmatrix(XMatrix,RMatrix); ] 
else VGmullongmatrix(XMatrix,RMatrix,RMatrix); ] 
if.(Yengle) | VGmullongmatrix(YMatrix,RMatrix,RMatrix); ) 
if (Zangle) | VOmullongmatrix(ZMatrix,RMatrix,RMatrix); ) 


if (Yengle) 
( 
if (clear) | VGcopylongmatrix(YMatrix,RMatrix); ) 
else ( VGmullongmatrix(YMatrix,RMatrix, 
RMatrix); ) 

if (Zangle) | VGmullongmatrix(ZMatrix,RMatrix, 
RMatrix); ) 

} 


else 


{ 
if (Zangle) 
[ 


if (clear) | VGcopylongmatrix(ZMatrix,RMatrix); } 


else Í VGmullongmatrix(ZMatrix,RMatrix, 
RMatrix); ) 
1 


) 


Listing 1. (Schluß) 


VEER, 
І VG - Vector Graphics I 
IT 
Heiko Schlichting І 
Dirk Mehren І 
Berlin / Cuxhaven І 
Ук и 
#ifndef VGH 
#define VGH 
#include <intuition/intuitionbase.h> 
#include <graphics/gfxbase.h> 
#include <exec/memory.h> 
#include <ctype.h> 
#include <stdio.h> 
#include <time.h> 
#ifdef AZTEC_C 
#include <functions.h> 
#endif 
#define INTUITION. 0x00000001 
#define GRAPHICS 0x00000002 
#define SCREEN 0x00000004 
#define LINEMEM 0x00000008 
#define POINTMEM 0x00000010 
#define, MATHFFP 0x00000020 
#define MATHTRANS 0х00000040 
#define VGDIM 4 
#define VGPI ((float)3. 4415926525) 
#ifndef LIBRARIES_MATHFFP_H 
#define ЕРОМЕ ((float)1.0) 
#define FPZERO ((float)0.0) 
extern int SPFix(); 
extern int SPF1t(); 
extern int SPNeg(); 
extern int SPAdd(); 
extern int SPSub(); 
extern int SPMul(); 
extern int SPDiv(); 
extern int SPSin(); 
extern int SPCos(); 
#endif 
/* ERRORMESSAGES */ 
#define ERR OPINTUITION 
#define ERR OPOFX 
#define ERR OPMATHFFP 
#define ERR OPMATHTRANS 
#define ERR OPSCR 
#define ERR OUTMEM 
#define ERR DISPX 
#define ERR DISPY 
#define ERR DISPB 
#define ERR NOTHING 
#define ERR FIRSTOPEN 
#define ERR_FALSERGB 
#define ERR_FALSEPAR 
#define ERR ALREADYOP 
#define ERR TOOMLINES 
#define ERR TOOMPOINTS 
#define ERR UNDEFPOINT 
#define ERR CANTOPENFILE 
#define ERR_LOWRESMEM 
union VGzahl | 
float f; 
int i; 
Ji 
struct VGLine | 
int Number; 
int StartPoint; 
int EndPoint; 
short Color; 
р 
struct VGPoint [ 
int Object; 
union VGzahl Koord[VGDIM]; 
Б 
struct VGColor | 
unsigned short R,G,B; 
); 


"OpenLibrary (Intuition)" 
"OpenLibrary (Gfx)” 
"OpenLibrary (MathFFP)" 
"OpenLibrary (MathTrans)” 
“OpenScreen” 

“Out of Memory” - 
"Invalid Viewresolution (X)” 
"Invalid Viewresolution (Y)” 
"Bitplane” 

"Nothing to do: 10010” 
"Requires VGopen" 

"Out of RGB bounds” 

“Out of Colortable” 

"Second VGopen without VGclose” 
"Number of Lines > MaxLines” 
"Number of Points > MaxPoints” 
"Line with undefined Point” 
"File not found, can't open it 
“Out of Line/Point-Memory” 


Listing 2. Das von »VG« benötigte Include-File »VG.h« 
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кк, 
І VG - Vector Graphics | 
[FREER EEEE EE EEEE EET] 
Heiko Schlichting I 

Dirk Mehren I 

Berlin / Cuxhaven I 
ТУ) 


#include “VG.h” 
#define ALLOBJ 0 
#define OBJ1 1 
#define 0872 2 
#define OBJ3 3 
#define OBJ4 4 
extern struct Screen *VGscreen; 
struct VGColor FarbTab1[4]={ 0x0,0x0,0x4,0xf,Oxf,0xf,0xb,0xb,0xb, 0x7, 
0x7, 0x7} ; 
struct VGColor FarbTab2[4]={0x8,0x8,0x8,0x0,0x0,0xf,0x0,0xf,0x0,0xf, 
0x0, 0x0] ; 
union VGzahl XMatrix[40][VGDIM)[VGDIM], 
YMatrix[40] [VODIM] [VGDIM], 
AMatrix[VGDIM][VGDIM], 
BMatrix[VGDIM) [VGDIM); 


main() 

( 

register int 1; 

int DeltaX,DeltaY,OldX,0l1dY, Grad; 
float ^ SVektor[3]; 


DeltaX=DeltaY=0; 

Grad=01dX=01dY=1; 

printf(’\nWenn die Bildschirmfarbe GRAU ist,\nkann das Objekt mit 
der Maus bewegt werden! \n”) ; 

printf("PROGRAMMENDE durch positionieren der Maus in der linken 
oberen Eckel\n”); 

printf(”\nWeiter mit RETURN\n”); 

getchar(); 

VGopen(320,256,2,100,100, "RAM:SYSPRINT”); 
VGrotate(XMatrix[20],-1,0,0, TRUE); 

VGrotate(YMatrix[20],0,-1,0, TRUE) ; 
VGrotate(XMatrix[19],+1,0,0,TRUE) ; 

VGrotate(YMatrix[19],0,*1,0, TRUE) ; 

for (1#0;1<19;1++) 


VGrotate(XMatrix[18-1],*0rad,0,0, TRUE) ; 
VGrotate(XMatrix[1*21],-Grad,0,0, TRUE) ; 
VGrotate(YMatriy[18-1),0,*Grad,O, TRUE) ; 
VGrotate(YMatrix[i+21] ,0,-Grad,0, TRUE) ; 
Grade; 
] 
VGreaddata( "VOTEST DAT) ; 
VGdisplay(TRUE); 
SVektor[0]=0.0; 
SVektor[1]=0.5; 
SVektor[2]=0.0; 
VGlocalscale(AMatrix,SVektor,0.25, TRUE); 
for (1=0;1<20;1++) 
( ў 
VGtransform(ALLOBJ, AMatrix) ; 
VGdisplay(TRUE) ; 


VGrotate(AMatrix,0,3,0, TRUE); 
for (1-0;1«180;14-3) 

( 

VGtransform(ALLOBJ , AMatrix) ; 

Vodisplay(TRUE); 

) 
VGlocalscale(AMatrix,SVektor,-0.08, FALSE) ; 
for (1=0;1<60;1++) 

{ 

VGtransform(ALLOBJ , AMatrix) ; 

VGdisplay(TRUE); 

} 
for (1=0;1<18;14+) ( VGline(36+1,1,1+18,2); ] 
VGrotate(AMatrix,0,3,4, TRUE) ; 
VGrotate(BMatrix,3,4,0,TRUE) ; 
for (1=0;1<360;1+=5) 

І 

VGtransform(0BJ1,AMatrix); 

VGtransform(0BJ3,AMatrix) ; 

VGtransforn(0BJ2,BMatrix); 
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VGco: 
VGro 
Vogl. 
VGtr: 
for 


P ROJEKT 


VGtransform(0BJ4,BMatrix) ; 
VGdisplay(TRUE) ; 


Lor(0,4,FarbTab1) ; 
tate(AMatrix,2,2,1,TRUE) ; 
obalscale(AMatrix,0.967, FALSE) ; 
anslate(ANatrix,0.2,0.3,-0.2,0.05, FALSE) ; 
(1-0;1« 20; i++) 


VGtrensform(ALLOBJ, Matrix) ; 
VGdisplay(TRUE) ; 


VGtranslate(AMatrix,0.2,0.3,-0.2,-0.04, TRUE) ; 


for 


VGgl 
for 


(1=0;1<20;1++) 


VGtransform(ALLOBJ, AMatrix) ; 
VGdisplay (TRUE); 


‚obalscale(AMatrix,1/0.967, TRUE) ; 
(1=0;1<20;1++) 


VGtransform(ALLOBJ , AMatrix) ; 
VGdisplay(TRUE) ; 


VGrotate(AMatrix,0,1,0, TRUE) ; 


for 


(2=0;1<30;1++) 


VGtransform(OBJ3,AMatrix); 
VGtransform(OBJ4,AMatrix); 
VGdisplay(TRUE); 


VGrotate(AMatrix,0,-1,0, TRUE); 


for 


(120;1«30; i++) 


VGtransform(0BJ3, AMatrix); 
VGtransform(OBJ4, AMatrix); 
VGdisplay(TRUE) ; 


VGtranslate(AMatrix,0.2,0.2,0.0,-0.02, TRUE); 


for 


(1#0;1<10;1++) 
{ 
VGtransform(ALLOBJ, AMatrix) ; 
VGaisplay(FALSE) ; 


VGeraseobj (ALLOBJ) ; 
VGdisplay (TRUE) ; 
VGreaddata( "VGTEST.DAT”); 


for 


(ї1=0;1<18;1++) ( VOline(36+1,1,1+18,2); } 


VGcolor(0,4,FarbTab2) ; 


HCH 


‘splay (TRUE) ; 


while (OldX 11 oan 


( 
DeltaX = OldX-(unsigned int) (VGscreen->MouseX) ; 
DeltaY = OldY-(unsigned int) (VGscreen->MouseY) ; 
OldX = (unsigned int) (VGscreen->MouseX) ; 
OldY = (unsigned int) (VGscreen->MouseY) ; 
if ((DeltaX < 20) 88 (DeltaX > -20) && DeltaX) 
( 
VGtransform(ALLOBJ, YMatrix[194DeltaX]); 
if ((DeltaY < 20) && (DeltaY > -20) && DeltaY) 
[ 
VGtransform(ALLOBJ , XMatrix[194DeltaY]); 
) 
if (DeltaY || DeltaX) | VGdisplay(TRUE); ) 
] 


VGclose(FALSE) ; 


Listing 3. 
»VGTest« demonstriert 


die 


fantastischen 


Fähigkeiten von »VG« 


Know-How 


Fortsetzung von Seite 62 


REGISTER SHORT 1; 
for(1-0;1« VS; i++) FreeVSprite(VSp[i],RP,VP,1); 
if(Ball) FreeMem(Ball,sizeof(BallDat)); 
if(GelsInfo) FreeGelsInfo(GelsInfo); 
if(win) CloseWindow(win) ; 
if (GfxBase) CloseLibrary(GfxBase) ; 
if(IntuitionBase) CloseLibrary(IntuitionBase) ; 
exit(0); 
] 
VOID OpenW() 
| 
REGISTER SHORT i,c,hm,x,y; 
if(!(IntuitionBase=(struct IntuitionBase X) 
OpenLibrary("intuition.library",0))) 
if(!(GfxBase=(struct GfxBase X) 
OpenLibrary("graphics.library",0))) CloseW();. 
Af (1 (win=OpenWindow(&nwin))) CloseW(); 
VPsViewPortAddress(win); 
RP=win->RPort; 
if(!(Ball=(WORD *)AllocMem(sizeof(BallDat) ‚MEMF_CHIPI MEMF_PU- 
BLIC))) 


CloseW(); 


CloseW(); 

CopyMem(Bal1Dat,Ball,sizeof(BallDat)); 
if(!(GelsInfo=GetGelsInfo(RP,0xFE,202,55,435,185))) CloseW(); 
SetCdl1ision(0,BorCon,GelsInfo) ; 
for(i=0;1<5;i++) SetCollision(i+1,MarCon,GelsInfo) ; 
for(c=1=0;1<VS;it+,ct++){ 

if(e>4) с-0; 

hm=2< <c; 

х=210+1%10; 

у-60%1%5; 

if(!(VSp(i]=GetVSprite(RP,x,y,7,hm,hm+1,Ball,Col[e], 


CloseW(); 
} 
DrawGels(RP,VP) ; 
) 
ULONG GetMessage(code) 
USHORT *code; 
( 


struct IntuiMessage *msg; 
ULONG class=0; 


if(msg=(struct IntuiMessage *)GetMsg(win->UserPort) ){ 
class=msg-> Class; 
*code=msg- > Code; 
ReplyMsg(msg) ; 


) 


return(class); 


] 


VOID main() 
І 
REGISTER SHORT 1; 
USHORT code; 
ULONG class; 
OpenW() ; 
while(1){ 
class=GetMessage(&code) ; 
if(class==CLOSEWINDOW) break; 
WaitTOF() ; 
for(1=0;1<VS;i++){ 
if(VSpC1])Í 
VSp(1]-» X4» VX(1]; 
VSp(1]-» Ys» vY(1]; 
} 
) 
DrawGels(RP,VP); 
DoCollision(RP); 
if(Idi«Id2)[ 
DisplayBeep(0); 
FreeVSprite(VSp[1d1],RP,VP,0) ; 
VSp[Id1]=NULL; 
141-142-0; 
) 
} 
CloseW() ; 


) 


Listing 4. Das Demo-Programm »VS« stellt 20 VSprites 
gleichzeitig in 15 Farben dar 
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AMIGA-SONDERHEFT 7 


HiSoft-Basic- 
Compiler 

Mit HiSoft Basic gibt es 
endlich auch einen Basic- 
Compiler für den Amiga. 
Der interaktive Editier-, 
Kompilier- und Laufzeit- 
zyklus entspricht dem eines 
Interpreters. 

Der integrierte Editor erlaubt 
eine komfortable Eingabe. 
HiSoft Basic unterstützt die 
Eigenschaften des Amiga mit 
Fenstern, Grafik-Kommandos, 
Sprite-Handling und Maschi- 
nenzugriffen während des 
Gebrauchs von Bibliotheken. 
Es ist voll kompatibel mit 
Amiga-Basic, andere Stan- 
darddialekte für den PC, wie 
z.B. Microsoft QuickBasic, 
und den Atari ST können mit 
geringen Modifikationen 
kompiliert werden. Rekursive 


Markt&Technik 


Zeitschriften - Bücher 
Software - Schulung 


Unterprogramme und Funktio- 
nen sind möglich. 

Eine Anzahl strukturierter 
Ausdrücke wie z.B. 
WHILE...WEND, DO...LOOP 
UNTIL und SELECT... CASE 
lassen Sie jede Programmier- 
hürde meistern. Die Größe von 
Variablen ist nicht beschränkt. 
Aussagekräftige Fehler- 


meldungen und Korrekturmög- 


lichkeiten tragen zur komfor- 
tablen Handhabung bei. 
Hardware-Anforderungen: 
Amiga 500, 1000 oder 2000 
mit Kickstart 1.2 oder höher. 
3'/,-Diskette, 

Bestell-Nr. 54127 

DM 179,—* 
(sFr 161,- 


185 1790,-*) 


Marsi, 


Devpac 

Assembler 2.0 

Devpac 2.0 ist ein Entwick- 
lungspaket für den Amiga 
mit komfortablem Editor/ 
Assembler, symbolischem 
Debugger und Linker zum 
Einbinden von Hochsprache- 
Modulen. 

GenAm ist ein 68000er-Makro- 
assembler mit integriertem 
Bildschirmeditor, der bis zu 
75.000 Zeilen pro Minute 
assemblieren kann. Der 2-Paß- 
Assembler erzeugt sowohl 
linkbaren als auch direkt aus- 
führbaren Code. Er unterstützt 
lokale Labels, die Signifikanz 
betrágt bis zu 127 Zeichen. 


FNFO-COUPON 77777 


NFO-COUPON 


Bitte senden Sie mir weiteres Informationsmaterial zu 
(4 Devpac-Assembler (1 HiSoft-Basic-Compiler 


І Мате 


2211/907 


Straße 


! PLZ/Ort 


Bitte ausschneiden und einsenden an: Markt&Technik Verlag AG, Buchverlag 
Frau Brosien, Hans-Pinsel-Straße 2, 8013 Haar bei München 


1 Ami SH 


-pL 


Мапата 


Makros können bis zu 36 Para- 
meter beinhalten und - Rekur- 
sion inbegriffen - so tief 
verschachtelt werden, wie 
Speicherplatz vorhanden ist. 
MonAm, der Debugger, 
erlaubt das Setzen von 
Breakpoints, das Disassem- 
blieren auf Diskette und noch 
weitere Features, die das 
Debuggen zum Vergnügen 
machen 
Hardware-Anforderungen: 
Amiga 500, 1000 oder 2000 
mit mindestens 512 Kbyte, 
ein Diskettenlaufwerk. 

37; -ізкейе, 

Bestell-Nr. 54131 

DM 149,—* 

(sFr 135,-*/68 1490,—*) 


Devpac-Assembler 2.0 

im Test! Amiga-Magazin 4/89: 
Eines der besten Programme 
seiner Art für den Amiga 


SuperED C 
Multitasking-fähiger Editor als 
Programmierumgebung für 
den Aztec-C-Compiler (V 3.6). 
Bestell-Nr. 54139 

DM 39,—* 

(sFr 35,-*/6S 390,-*) 


* Unverbindliche Preisempfehlung 


clevere Amiga-User verwenden gleich 


ProMigos 


denn wir verwenden nur ausgesuchte Qualitätsware für unsere Produkte, die auch höchsten 
Ansprüchen gerecht werden. Und das bei einem sehr guten Preis-Leistungs-Verhältnis!! 


ProMigos Zubehör 
rund um den Amiga: 


elektronischer Bootselektor 
wahlweise booten von DF0: — DF2; (optional auch DF3:) 


nur 58,00 DM 
ROM/ROM Kickstart-Umschaltplatine 


Zwischen zwei original ROMs (40polig) umschalten 


nur 49,00 DM 
ProMigos3,5"-Floppystation 


abschaltbar, durchgeführter Bus, extrem leise, 
NEC-Drive 

nur 279,00 DM 
ProMigosBoot-Strap-Platine 


beliebige Kickstart wie beim A1000 aus RAM booten 
(Lieferung ohne RAM & A1000-BootROMs) 


nur 98,00 DM 


ProMigos Autoboot-Harddisk- 

Station für A500 & A1000 
Kapazität von 20 bis 110 MByte, 
ALF2-Treibersystem inkl. Backup-Software 


ab 1168,00 DM 


* bitte ausführliche Info anfordern 


* ProMigos-Produkte erhalten Sie 
direkt bei uns 
oder im guten Fachhandel 


* deutsche Qualitätsfertigung 
* Ausländische Distributoren gesucht 
e Hàndleranfragen erwünscht?! 


ProMigos 512 KByte RAMCARD 


mit eingebauter Uhr, abschaltbar, für A500 


nur 319,00 DM 


ProMigos Kickstart-Umschaltplatine 


zwischen einem ROM & zweimal Eprom umschalten 


nur 68,00 DM 


ProMigos5,25"-Floppystation 
40/80 Track, abschaltbar, durchgeführter Bus, 
TEAC-Drive 


nur 349,00 DM 
Autoboot-Upgrade-Kit 


Autoboot-Upgrade-Kit für vorhandene ProMigos & 
Amigos Harddiskstationen inkl. ALF2-Treiber und 
Backup-Software 


nur 248,00 DM 


ProMigos Autoboot-FileCard für A2000 
Kapazität von 20 bis 50 MByte (intern), ALF2- 
Treibersystem inkl. Backup-Software 


ab 1120,00 DM 


Amiga und Commodore sind eingetragene Warenzeichen der Firma Commodore Inc. 


Flesch & Hörnemann Computer OHG 
Schlägel & Eisen Straße 46 

4352 Herten 

Telefon: 049-023 66-5 5176 

Telefax: 049-0 23 66-5 3450 


